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Foreword 


The NASA Johnson Space Center (JSC) primary 
research and development thrusts include: human spacecraft 
development, human support systems, and human 
spacecraft operations. We have invested significant 
resources in developing infrastructures such as facilities and 
partnerships that will enable us to address major 
technologies and cost-effective approaches for present and 
future Agency missions. We have already reported progress 
made in some of our projects in the 1992 Research and 
Technology Annual Report (RTAR). Only efforts pursued 
under Research and Operating Plans (RTOPs) are reported 
in the RTAR in a format suggested by NASA Headquarters. 
In consultation with academia, research institutions, 
industry, and JSC organizations, the need for reporting 
progress made on many of our projects in support of human 
spacecraft design, development, and operation was 
established last year. As a result, we are issuing for the first 
time this Research and Development Annual Report 
(RADAR) as a complement to the RTAR. 


In all of our efforts, we actively seek and foster 
collaboration with other NASA centers, government 
agencies, academia and research communities, and industry. 
I believe sharing the knowledge through this report is 
crucial to the continued growth of this collaboration. Our 
goal is to provide reports which are responsive to the needs 
of our partners in industry, academia, and government 
communities. To this end, your comments and suggestions 
will be highly appreciated and should be mailed to 
Dr. Kumar Krishen, Code IA4, NASA Johnson Space 
Center, Houston, Texas 77058, or faxed to 713-244-8589. 



Aaron Cohen 

Director, Johnson Space Center 
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INTRODUCTION 


The decision to publish the Johnson Space Center 
(JSC) Research and Development Annual Report 
(RADAR) was made through a detailed process involving 
industry, academia, research institutions, and JSC 
organizations. These groups identified the need for a 
method of reporting significant JSC accomplishments 
which are not funded by Research and Technology 
Operating Plans (RTOPs). That work which is funded 
through RTOPs is currently reported in the Research and 
Technology Annual Report (RTAR); RADAR will serve 
as a complement to that report. Concurrent with 
identifying a need for the RADAR, a more detailed 
format than the one used on the RTAR was developed. 
The enthusiastic support of JSC organizations produced a 
number of submissions, from which we selected a variety 
of papers that illustrate the substantial accomplishments 
JSC achieved in 1992. 

This report describes projects that support the 
primary mission of JSC and focus on human spacecraft 
design, development, and operation. Also of prime 
importance to JSC mission success are support systems 
that are essential to human spacecraft safety and 
reliability. As a consequence of the emphasis at JSC on 
human spacecraft research and technology, the results of 
our activities have found and continue to find wide 
applications in civil and commercial areas. In a recent 
review, the JSC Technology Coordinating Committee 
Action Team 1 developed a list of JSC technologies and 
markets which could potentially benefit from our research 
and development. A summary of these technology 
development activities is listed in table 1. 

The emerging technologies at JSC include advanced 
materials, superconductors, advanced semiconductors, 
digital imaging, high density data storage, high 
performance computers, optoelectronics, artificial 
intelligence, flexible computer integrated manufacturing 
(robotics and automation), sensor technology, 
biotechnology, medical devices and diagnosis, life 


support, extravehicular and intravehicular activity (EVA 
and IV A) and human factors. JSC is expending 
substantial effort in developing interdependent research 
and technology programs with the Department of 
Defense, the Advanced Research Projects Agency, the 
Ballistic Missile Defense Organization, and the 
Department of Energy. The principal goals of these 
programs are to promote communication, share lessons 
learned, and realize cost savings through shared facilities 
and resources. Also being developed are partnerships 
with universities and research institutions to address 
critical research and development that will require their 
participation. Finally, we are promoting the transfer of 
our knowledge and technology to academia and industry 
to strengthen America’s industrial competitiveness. We 
have an impressive record of achievements in technology 
transfer and are redoubling our efforts in this area. 

We are eager to communicate the results of our 
research and development in all areas. To this end, we 
decided to issue the first RADAR to complement the 
RTAR. We deliberately chose a format which gives more 
detailed descriptions of the projects than the RTAR. In 
the years to come, we believe RADAR will become the 
Center’s unique report which highlights our yearly 
research and development accomplishments. 

Your feedback and comments will be crucial in 
making this report valuable to the community of 
managers, researchers, academicians, and developers it 
serves. Should you have any comments or suggestions, I 
can be reached via fax at (713) 244-8589. 



1 Robert Ried, Bill Eggleston, Kumar Krishen, Audrey Schwartz, Earle Crum, Dick Ramsell, Bob Savely, James Villarreal, 
Phil Deans of JSC and Robin Lineberger of KPMG. 
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Table 1 . JSC Technology Development Activities 


EMERGING 
TECHNOLOGY/JSC 
TECHNOLOGIES 
Advanced Materials 

• Ceramic Composites 

• Space Durable Coatings 

• Entry Thermal Protection 
Systems 

• Hypervelocity Impact Shield 

• Fracture Mechanics 
Analysis Tools 

Superconductors 

• Antenna System 
Applications 

• Magnetics Systems 
Applications 


Advanced Semiconductor 

• Vertical Stack Devices 

• X-Ray Lithographic 

• Gallium Arsenide 

• Elching 

• Ebeam, Epitaxial Bonding 

• Analog Devices, DSP 
» Biosensors 
Digital Imaging 

• Pattern Recognition 

• Virtual Reality 

• Video Rate Image Warping 

• DSP 

• High Definition Television 

• Chromosome Analysis 

• Digital Image Compression 

• Retinography 

• Electronic Still Camera 


High Density Data Storage 

• Ferroelectric 

• CD ROM 

• Gigabyte Storage 


High Performance 
Computers 

• Parallel Processing 

• Neural Networks 


INTERNATIONAL 

COMPETITIVE 

POSITION 

Certainly competitive 
and probably leading in 
all areas. 



JSC requirements are 
drivers of technology for 
space specific 
applications. 

Available US technology 
is about even with the 
Japanese. 



LIKELY MARKETS 

• Aerospace/Defense/ 
Space 

• Construction Industry 

• Consumer Products 

• Manufacturing 

• Engineering (Fracture 

Analysis) 

• Aerospace 

• Manufacturing 

• Energy 


• Telecommunications 

• Satellites 

• Microwave 

• IR Detectors 

• Fiber Optics 


• Medical/Health Care 

• Computer/ 
Communications 

• Law Enforcement 

• Nuclear Industry 

• Environment 

• Photo Industry 

• 1C Industry 

• Mapping 

• Aerospace/Defense/ 

Space 

• Computer 

• Aerospace/Defense/ 
Space 

• All Industry Users of 

Computers 

• Computer 

• Aerospace/Defense/ 
Space 

• All Industry Users of 

Computers 



• JSC coordination with 
high temperature 
superconductor 
researcher on antenna 
applications. 

• Magnetic systems 
may have later 
applications to 
spacecraft docking 
and payload handling. 



• Strong benefit from 
existing Technology 
Utilization program 
and from ties with 
military partners, 
DARPA and national 
labs. 


• JSC is currently 
applying these 
technologies. 
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Table 1 . JSC Technology Development Activities (Continued) 


EMERGING 

TECHNOLOGY/JSC 

TECHNOLOGIES 

Optoelectronics 

• Spatial Light Modulators 

• Fast Joint T ransformation 
Correlators 

• Optimal Filter Theory 

Artificial Intelligence 

• Expert Systems 

• Fuzzy Logic 

• Neural Networks 

• Automation of Operations 

• Automation of Eng. 

Analysis 

• Human-Computer 
Interaction 

Flexible Computer 
Integrated Manufacturing 
(Robotics/T elerobotlcs) 

• Telescience 

• Virtual Reality 

• Remote Operator 
Interaction 

• Integrating SSF Robots for 
Assembly and Maintenance 

• Dextrous End Effector 

• Evaluating Robotic 
Technologies 

• Fault Tolerant Robots 

Sensor Technology 

• Types/Categories (Infrared, 
Nuclear Magnetic 
Resonance, Magnetic, 
Ultrasonic, Temperature, 
Chemometric) 

• Impedance Imaging 

• Smart Sensors 

• Plasma Grid Detector 

• Backwater Mossbauer 
Spectrometer (BAMS) 

• Thermal Analysis Analyzer 

• Ultra Sensitivity 

Instrumental Neutron 
Activation Analysis 

Biotechnology 

• Bioreactor 

• Tissue Equivalent 
Proportional Counter 
(TEPC) 

• Cell Support Systems 

• Understanding of 
Osteoporosis, Immunology, 
Cell Biochemistry 


INTERNATIONAL 
COMPETITIVE 
POSITION 

JSC conducts and • 

supports state of the • 

art work In filter theory. 


• Overall competitive: • 

application of high 
performance 
computing to Al and 
Expert systems. 

• Lagging: advanced 
software engineering, 
fuzzy logic, and neural 
networks. 


• As far as space • 

robotics is concerned, • 

the JSC program is • 

the best in the world. 

With respect to 
robotics in general, 

JSC is competitive. • 


LIKELY MARKETS 

Medical 

Manufacturing 


Al can be applied to 
virtually any industry. 


Medical Technology 

Automotive 

Chemical 

Environmental 

Cleanup 

Petrochemical 

Manufacturing 

Telerobotics 

Aerospace/Space/ 

Defense 

Most industries will 
benefit from this 
technology 
development area, 
especially the medical 
and health care 
industries. 


Aerospace/Defense/ 

Space 

Nuclear Power 
Pharmaceutical 
Biotechnology 
Health Industry 


COMMENTS 

• The JSC program has 
benefited more from 
military funding and 
cooperation than from 
NASA funding. 



Benefits of JSC sensor 
technology include 

• Noninvasive 
Monitoring 

• Reduction in Size of 
Equipment 

• Decrease Cost of 
Health Care 


• SSF will play a major 
driving/applying role in 
this area. 

• JSC Bioreactor is 

being marketed by 
Synthecon, Inc. 
through a JSC 
technology utilization 
program, 
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Table 1 . JSC Technology Development Activities (Continued) 


EMERGING 

TECHNOLOGY/JSC 

TECHNOLOGIES 

INTERNATIONAL 

COMPETITIVE 

POSITION 

LIKELY MARKETS 

COMMENTS 

Medical Devices and 
Diagnosis 

• Image Warping and 
Patterned Sensors 

• Joint Transformation 
Correlation 

• Data Reduction and 
Analysis Algorithms for 
Sensors 

• Dried Blood 
Collection/Analysis 
Techniques 

• Behavorial Performance 
Devices/Algorithms 

• Echocardiography 

• Electrical Muscle 
Stimulation 

• Robust Exercise Equipment 

• Medical Equipment 
Computer 

• Advanced Life Support 
(Training, Equipment, 
Supplies and Layout) 

• Competitive for the 
category 

• Leading in the 
development of an 
integrated portable 
medical computer 
system, and in 
innovations on training 

• Medical/Health Care 

• Education 

• Sports 

• Aerospace/Defense/ 
Space 

• Law Enforcement 

• Consumer Products 

• Environmental 

• Strong benefit from 
existing technology 
utilization program 

• Working with 
University of Texas 
Medical School and 
Baylor University 
Medical School in 
medical 

devices/diagnosis 

areas 

Ufe Support 

• Air Revitalization 

• Water Recovery 

• Food Storage and 
Preparation 

• Waste Management and 
Processing 

• Resource Recovery 

• Thermal Control 

• Long Duration Testing 
(Testbed) 

• Environmental Quality 
Monitoring Technology 

• Closed Environment 
Requirements and 
Microbiology and 
Toxicology 

In general terms, those 
systems/requirements in 
the US are similar to the 
Russians; the technolo- 
gies are roughly equiva- 
lent The Russians are 
ahead of US in regen- 
erative life support 
technologies because of 
their utilization of those 
technologies on the MIR 
space station. 

• Aerospace/Space 

• Environmental 

• Medical 

• Construction/Building 

• Agriculture/Food 
Processing 

• JSC efforts in 
biological life support 
very closely parallel 
the natural 

environment and may 
have potential for 
helping environmental 
problems on Earth. 

EVA 

• Air Revitalization 

• Thermal Control 

• Power/Batteries 

• Displays and Control 

• Weight Reduction 

• High Mobility 

• In-Suit Monitoring 

• Mobility/Ease of Work 

• Protection from 
Decompression Sickness 

Generally ahead of the 
Russians in that the US 
uses a combination of 
throw-away, low logistics 
systems, and 
regenerative systems, 
whereas Russia 
generally uses only 
throw-away systems. 
The Europeans are 
expected to use 
American technology. 

• Aerospace/Defense/ 
Space 

• Nuclear 

• Environmental 
Cleanup 

• Medical/Health Care 

• Hazardous 
Environments 

• Manufacturing 
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Table 1. JSC Technology Development Activities (Concluded) 


EMERGING 

INTERNATIONAL 



TECHNOLOGY/JSC 

COMPETITIVE 



TECHNOLOGIES 

POSITION 

LIKELY MARKETS 

COMMENTS 

Human Factors 




• Anthropometry and 


• Aerospace/Defense/ 

• Animation Software 

Biomechanics 


Space 

and Human Modeling 

• Computerized Human 


• Architecture 

Available to Public 

Modeling 


• Medical Technology 

• Research Products 

(Animation, Lighting) 


• Education 

Passed on to Industry 

• Human-Computer 


• Sports (Equipment 

and Universities; Will 

Interfaces 


and Training) 

Benefit Consumers 

• Virtual Reality for EVA 


• Law Enforcement 

and Quality of Life 

• Personal Emergency 


• Manufacturing and 

• SSF and Advanced 

Provisions 


Design 

Programs Important 

• Tools and Diagnostic 


• Consumer Products 

Drivers in This Area 

Equipment 


• Environmental 


• Escape Systems 


* Mapping 


• Crew Health Care Systems 


• Software and 


— Countermeasures 


Hardware 


• Display Panels 


Development 


• Computer Input Devices 


• Subsea Exploration 


• Instrument Noise 


• Nuclear Plant 


Abatement 


Operation 


• Instrument Vibration 


• Food Industry 


Isolation 




• Performance Evaluation 




• User Friendly Science 




Monitoring Workstations 




• Crew Systems 
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The Flight Analysis and Design System 


Charles F. Deiterich 
Johnson Space Center/DC 


Abstract 

The flight and analysis system is a computational 
environment, including application software, that supports 
the Space Shuttle Program in the area of flight design. This 
system was developed to replace several specialized and 
separate systems which mainly evolved from engineering 
tools. FADS is an integrated system which provides 
electronic data sharing, increased throughput for both 
production and analysis and high productivity for the flight 
designer. 

Introduction 

The Flight Design Computational Facility (FDCF) 
systems have been the cornerstone of the flight analysis and 
design efforts at JSC for the Shuttle Program; they have 
supported all Space Shuttle Program (SSP) flights through 
1992. A flow evaluation team (1986-1988) determined that 
the support environment could not prepare for the expected 
flight rates by 1992 without an unacceptable increase in 
either personnel or program risk. It was also determined 
that the flight design (FD) process was computer resource 
limited, not manpower limited. The flight analysis and 
design system (FADS) development effort (1989-1992) 
responds to this identified need of safing the FD support 
system by 1992. 

FADS is intended to increase system safety by 
reducing manual data entry and increasing designer 
efficiency. These results are expected through the use of: 

• Electronic transfer of both internal and external products 

• Archiving of products for later use or analysis 

• Common and automated services for input processing and 
output processing, including data checking 

• A data base to allow sharing of data between applications 

• Reduced turnaround times 

Description 

The flight design and analysis system is a computer 
environment that provides the computational base of the 
highly complex and critical FD process. Flight design is the 
process of integrating payload requirements and mission 
objectives into a mission and trajectory design that satisfies 
SSP and Orbiter constraints, ground capabilities, and crew 
procedures and constraints. Flight design supports the 
following: 

• Mission reconfiguration of ground facilities, such as the 
Mission Control Center (MCQ and the Shuttle mission 
simulator (SMS) 

p. 
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• Flight software reconfiguration for the Shuttle onboard 
computer systems, both the primary avionics software 
system and the backup flight system 

• Plans and procedures used by the flight crew and flight 
control team 

• Direct mission support that, on flight day, updates the 
onboard computer ascent guidance profile and provides 
entry/landing analyses prior to deorbit of the Shuttle 

• Analyses and special studies 

Approach 

Flight design is a highly critical element of spaceflight 
from several points of view. 

Products from the FD process are necessary to support 
complex training activities for both the ground controllers 
and flight crew. Mission success is very dependent upon 
trajectory design, maneuver targeting, and other FD 
products that directly support vehicle rendezvous, payload 
deploy/retrieval, consumables utilization, etc. From a safety 
aspect, the ascent guidance information (called I-loads or 
computer initialization loads) provided to the onboard 
computer is most critical for control of the Shuttle during 
powered ascent, followed by the guidance, navigation, and 
targeting parameters for deorbit, entry, and landing 
execution. 

Of special note is the direct mission support activity 
that recalculates the ascent profile to update the Shuttle 
computer based on launch day-measured winds. Vehicle 
structural loads and ascent performance are predicted based 
on the flight day-measured environment received 
electronically by FADS. Ascent targets are modified as 
required to eliminate any loading violations and are tested 
via computer simulation. After review, these values or 
I-loads are electronically transferred to the Shuttle onboard 
guidance computer. Additionally, atmospheric flight 
analyses based on actual winds are used to support landing 
site selection and subsequent Shuttle flights through landing 
and rollout. 

The FD process is supplied with a vast amount of input 
data from a variety of sources. Generally, the source of 
flight-specific input data is the Space Shuttle Program 
Office. Input include requirements, constraints, and 
characteristics. The data describe the Orbiter vehicle and 
configuration rules and guidelines, mission objectives (i.e., 
payloads, experiments, and test objectives), ground facilities 
(including capabilities and use criteria for launch and 
landing sites, control rooms, relay satellites, and ground- 
based communication sites), status and schedules of 
resources, special analyses and studies, and public affairs 
functions. 




Computer 



The outputs consist of analysis, design, reconfiguration, 
and flight support products and services. The primary flight 
design output is a mission trajectory baseline that is used in 
Orbiter software, MCC operations, vehicle launch loadings, 
and program commit-to-flight activities. Alternate and 
contingency plans and data are also produced. 

This FD process includes a feedback loop from the FD 
activities back to the source of input data, making it an 
iterative process between FD and the data sources. The 
major objective of this loop is to be able to redefine input so 
that all incompatible mission-related objectives, 
requirements, and constraints can be resolved. 

There are many FD interfaces. Flight design receives 
input data and direction from the Flow Process Panel, from 
the Space Shuttle Program Office, and from the various 
configuration control boards. 

Products and services of FD support crew activity 
planning, flight software generation, flight software 
verification, and mission development for other NASA and 
military centers. 

Three general types of functions are performed by FD: 
analysis, flight product generation, and mission support. 
Singularly or in combinations, these functions are 
performed to achieve the objectives of FD. 

• Analysis is an engineering investigation of various 
plausible options to determine which, if any, option 
achieves a pre-defined mission objective. 

• Production is the preflight generation and dissemination 
of pertinent operational data and information for selected 
options. 

• Direct mission support is the provision of experienced FD 
support to the real-time operational flight support team 
during actual or simulated flights. The majority of this 
support is related to trajectory topics. 

The functions of FD can be characterized by an 
integrated system of generic models that converts various 
input data into FD output products. Output data are 
generally produced through the use of software tools 
installed on a computer or other hardware facility. By using 
established methods and procedures, the flight designer 
guides the process that translates input data into the desired 
output. 

Some FD functions are iterative. That is, the results of 
the process are submitted back into the function for 
subsequent processing. Often, the use of output data is the 
major determining factor of the number of processing 
iterations necessary to complete the objective. 

Many FD processes involve several functions. Each 
function performs a task that provides data to one or more 
other functions. The sum of the process structure — that is, 
the process network of functions — produces one or more 
objective output or products. 

Each task performed within a network of functions is 
the responsibility of a single FD discipline (e.g., ascent). To 
satisfy the objectives, however, one or more FD disciplines 
may be called upon to perform discipline tasks. The final 
output of the process may be produced as a cooperative 
effort of many different elements of FD. Details of various 


tasks performed by FD are documented in the Flight Design 
Handbook (FDHB). 

An outcome of performing FD functions is that a 
number of data products are produced or services are 
rendered. The information contained in the data or the 
services rendered may be one or more of the following 
general types: 

• Techniques are developed through analysis and are 
usually required when new or unique situations are 
encountered in a flight profile. Examples of this type of 
product include targeting methods for propulsive 
maneuvers, sequence of trajectory events in orbit 
operations, and propellant dump sequences. 

• Design is the use of accepted techniques to develop 
standard flight products; for example, the nominal or 
unchanging trajectory in a flight path. 

• Reconfiguration data and information are delivered to 
operational elements and facilities for those elements and 
facilities to reconfigure for the upcoming flight. 

• Flight support is an FD service that supplies FD data and 
information in support of operational flight control 
elements either during simulation or actual flights. 

Within the list of product categories, we find a variety 
of product properties. This is because of the varied use and 
required media of the receiving facilities. FADS has been 
designed and implemented to support the following product 
properties: 

• Product complexity - Some FD products are simple 
values that represent some state or condition. Other 
products may contain information with complex and 
interactive relationships that will require a high degree of 
specific knowledge to comprehend fully. 

• Product form and format - Products are produced in a 
variety of forms and formats. These forms and formats 
include tables, charts, drawings, text, etc. 

• Volume of information - The FD product volume varies 
from a few data values to thousands of pages of printed 
tables and reels of magnetic tape. A few products are 
extremely voluminous and require massive storage 
methods. 

• Product category - Each FD product is categorized by its 
potential or actual effect on the mission. At one end of 
the spectrum are those products that influence crew and 
vehicle safety and mission success. At the other end of 
the spectrum are those products that are generated for 
other purposes, such as public relations. 

• Product media - Product media used within FD include 
electronic and magnetic tape, paper, microfiche, and other 
photographic means. The media are determined by the 
product user and flight designer facilities (e.g., hardware), 
the product’s use (e.g., in support of a meeting), the 
proximity of the user to the flight designer, etc. 

FADS is the primary computational capability for FD 
activities for the SSP. 

Flight-specific information and mission requirement 
parameters are collected within FADS, are assessed, and are 
used to initialize and support FD computations and resulting 
products for SSP flight preparation. The open systems 
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design and the use of commercially available system service 
and user interface software have deemed FADS to be the 
platform of the future. Although Shuttle flight design was 
the initial FADS objective, Space Station Freedom (SSF) 
flight planning, design, and direct mission support are being 
implemented on FADS. The SSF capability will provide 
premission (pre-increment) planning for trajectory, vehicle 
consumables, power, logistics, maintenance, and crew 
activity scheduling, as well as for mission controller 
analyses and planning during the conduct of the actual SSF 
mission. Thus, this is the first step in demonstrating the 
ability of FADS to support future planning applications of 
yet to be defined programs. 

Results 

A description of FADS use and a system description 
follows: 

• FADS provides the capability to produce detailed SSP 
FDs. Input to these flight designs are mission manifest 
requirements, payload operations constraints, MCC flight 
rules, and data that describe the Space Shuttle and its 
payloads (e.g., mass properties, aerodynamics, etc.). 
Detailed FD output include launch windows, predicted 
trajectories, onboard computer guidance parameters, 
groundtrack and communication coverage information, 
attitude profiles, consumables usage, payload deploy 
conditions, rendezvous and/or docking sequences, etc. 
This information is provided to the Software Production 
Facility, the MCC, the Shuttle Mission Training Facility, 
the Shuttle Avionics Integration Laboratory, other NASA 
centers, the Range Safety Office at Patrick Air Force 
Base, payload organizations, etc. 

• The platform is a totally networked system with 

270 workstations, 27 file servers, 4 compute nodes, 2 data 
nodes, an archive server, and associated peripherals such 
as printers and plotters. Across the system there will be 
412 Gbytes of storage, not including the unlimited storage 
of the archive server. About 2.4 million lines of code 
(ANSI C, FORTRAN 77, and commercial off the shelf 
(COTS) fourth-generation language) are contained within 
FADS which is a total of 553 programs that represent 
menus, scripts, and trajectory applications. 

• The system is menu-driven and supports batch, demand, 
and interactive jobs. Electronic data handling eliminates 
most manual input; turnaround time and system access 
are greatly improved over the current system. All of 
these things help the flight designer do a better and more 
precise job. As for the software developers, computer- 
aided software engineering tools, documentation, and 
other associated utilities reside on FADS to assist in the 
software developers’ activities. 

Significance 

Implementation of the FADS program provides 
significant improvement for flight design efforts at JSC in 
support of the SSP. FADS: 


• Increases the safety of the FD process through reduction 
of errors inserted by the manual data handling needs of 
the former system. FADS provides for electronic data 
transfer, predefined or boilerplate data preparation scripts, 
a data management system for storage and control of all 
official data, and increased data management tools and 
processes. 

• Affords flight designers vastly increased productivity 
through the use of preset menus, the automation of data 
manipulation processes, the ability to retrieve archived 
analyses rather than recreating them, better and hands-on 
training for new flight designers, and a standard look and 
feel for the user interface across the entire user 
community. 

• Increases capacity and throughput by an order of 
magnitude. The flight designer can now turn around a 
large simulation of the Shuttle vehicle dynamics in a 
matter of a few minutes instead of the 2 to 3 days 
previously required. This will allow the design of Shuttle 
flights within a shorter template and with a minimum of 
user wait time. 

• Improves reliability and maintainability through the use 
of standard designs for system services, instead of 
multiple vendors with multiple operating systems. There 
is also an endless variety of graphics and reporting 
services to maintain, common approaches to software 
design across disciplines rather than 13 different ways of 
doing things, the use of COTS products instead of custom 
software developments, and the use of an open systems 
approach to the architecture and components provided 
with FADS. 

• Will simplify any modification to the system that is 
required in the future and will afford future savings as 
well. FADS is designed to be modular in all hardware 
and software aspects. Increased capacity can be achieved 
by the addition of small increments in workstation 
population. Reductions are also simplified if flight 
designer productivity increases to the point where 
equipment can be excessed. Individual workstations or 
entire suites of workstations, file servers, and compute 
nodes can be deleted from the system without loss of 
service for the remaining functions. 

The significance to NASA is described in the 

objectives and associated accomplishments. Objectives of 

the FADS are to: 

• “Safe” the Space Shuttle flight design system by 
providing a modem computer system that would 
minimize the manual data entry requirements in support 
of the hundreds of flight products required each year by 
the SSP flight rate. 

• Solve the problem of the long user computer run 
turnaround time that existed with the flight design 
computer facility (FDCF) system. 

• Provide a more efficient computing capability that would 
allow the flight design manpower requirements to be 
reduced by 50 equivalent persons (EP) per year. 

• Consolidate and improve the over 3M lines of computer 
code that were part of the FD process. 
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• Provide an electronic media for the FDHB (a desirable 
but not mandatory requirement) that would allow the 
flight designers easy access to process documentation. 

To accomplish these objectives we must: 

• “Safe” the Space Shuttle flight design system. With the 
workstation, compute node, and data node capability of 
the FADS system, an enormous amount of manual data 
entry requirements has been eliminated. With the 
electronic storage capability of FADS, almost all of the 
old system requirements for paper or microfiche products 
have been eliminated. This capability to eliminate 
microfiche was a significant factor in a separate Mission 
Operations Directorate initiative to reduce costs by 
deleting most of the microfiche facility. All of the 
objectives were met in “safing” the FD process. 

• Solve the problem of the long user computer run 
turnaround time. With the compute power of the FADS 
system, the turnaround time problem has been completely 
eliminated. Computer runs that took hours to execute and 
days to get output on the FDCF system are being 
processed in a matter of minutes on the FADS system. 

• Provide a more efficient computing capability. Asa 
result of the FADS system design, the goal of reducing 
the flight design manpower requirements by 50 EP has 
been met and is effective as of FY93. In addition, the 
operating cost for the FADS system as compared to the 
FDCF system has allowed a reduction of approximately 
$2.5M per year. This cost savings is effective as of April 
1993. As a result of the application software 
consolidation effort, the Space Transportation System 
Operational Contract materials and maintenance budget is 
being reduced by 7 EP starting in FY94. 

• Consolidate and improve. At the beginning of the FADS 
project, the FDCF contained 851 configuration items and 
had a code count of 3,694,600 lines. Most of this code 
was obsolete FORTRAN code. At of the end of 
September 1992, the FADS system contained 258 
application configuration items and had a total application 
code count of 1,951,215 lines (a reduction of 
1,743,385 lines). A1 of the code had been upgraded to 
modem FORTRAN or to C code. As a result of the 
electronic interface capability of FADS, 117 config- 
uration items of scripts and menus had been added to 
FADS. With this new code, the total FADS code count is 
2,376,547 lines. This represents a net code savings of 
1,318,053 lines. 

• Provide an electronic media. The FADS system has 
delivered a capability for electronic display of the FDHB 
through the Framemaker COTS package. With this 
capability, the flight designer can use the windowing 
capability to display the product and process procedures 
at the same time the product is being executed on the 
FADS system. 

Assessment of Use 

FADS is now fully operational and is being employed 

by all disciplines for all phases of FD activity. This has 

Computer 


allowed us to eliminate the UNIVAC system, the Pyramid 
system, the Aliant systems, and the Perkin-Elmer systems 
from our inventory, thus reducing our operations costs in 
the maintenance of multiple systems. Development of new 
flight designers has been vastly improved with hands-on 
training of the FD processes. The engineering change cycle 
has been greatly reduced, which is a direct effect of the new 
structured software development environment. And, most 
importantly, the automation of data preparation processes 
has eliminated manual data manipulation and entry and has 
provided a measure of safety that was sorely needed. 

FADS was developed to address some specific safety, 
capacity, and productivity concerns. Definite improvement 
in efficiency and productivity has already been seen. The 
existence of FADS, however, will foster a revolution in our 
approach to flight design for the SSP, thus providing 
tremendous potential for further and greater improvements. 
As designers and users become familiar with the benefits 
afforded by the FADS distributed environment, they will 
devise new approaches to their tasks. Anticipated 
improvements include conversion of batch applications to 
interactive processors, increased use of direct graphical 
interfaces instead of selection menus to simplify the user 
interfaces, consolidation of some serial functions into 
strings of processors that run together, and possibly even 
consolidation of disciplines or the generation of end-to-end 
FD applications. 

FADS has been implemented to provide a long-term 
FD computation capability. Much of the design is based on 
allowing hardware, systems software, and COTS services to 
be replaced with minimal impact. As SSP support to the 
SSF and other advanced programs commences, the role of 
FADS in the flight preparation function will increase. In 
addition, the capability for SSF preflight preparation and 
direct mission support for trajectory control and flight 
planning is being added to FADS. FADS access is being 
expanded to provide support in the SSF preincrement area 
and in the Control Center Complex for actual mission 
control. 

The FADS platform is a distributed processing 
environment with high-powered workstations 
interconnected to compute with data facilities. These will 
meet the basic needs of most NASA systems, which means 
the FADS design can service the needs of programs 
stretching from SSF support requirements (locally at JSC) 
to any administrative, engineering, or scientific tasks at any 
NASA facility. The FADS software design can provide FD 
simulation and trajectory planning needs for most NASA 
vehicles. 

Creativity 

The primary design approach to FADS is based on the 
concept of “open systems.” This approach precludes a 
dependency on proprietary products and customized system 
elements, and it allows open competition for component 
replacement with minimal impact. The portable operating 
system interface for computer environments operating 



system standard, ANSI “C,” and ANSI FORTRAN 77 are 
specified. 

The use of COTS hardware and software is to be 
maximized with only a minimum of custom software for 
mandatory system services. This approach has a smaller 
development cost and reduces the in-house sustaining 
engineering support. 

A “bundled” acquisition process was used to procure 
COTS hardware and software. This new process involved 
the integration of all of the platform requirements and 
design constraints into one procurement. Bundled 
acquisition reduced the time required for procurement and 
greatly reduced the risk for the integration of COTS 
hardware and software instead of focusing on the technical 
accountability for platform implementation. 

A distributed system is defined. Workstations are the 
user interface to FADS and, as such, allow immediate 
response for input and output data processing. Interactive 
trajectory and small to medium batch applications are 
executed on the workstation; however, the powerful 
compute nodes provide excellent throughput for large and 
highly iterative programs. 

To gain the necessary background to produce adequate 
design requirements, a time-consuming and extremely 
difficult task of analyzing the evolving and very complex 
FD process would have been needed. In lieu of this study, 
workload reference models based on current system were 
developed and transformed into performance sizing needs. 
Similarly, data models were developed to determine mass 
storage sizing and specifications for centralized data storage 
for shared data. 

A menu-driven system and a standardized user 
interface using COTS and common utilities were designed, 
which resulted in a user-friendly and productive tool. 

With the advent of the increased standards for 
automated information security (AIS), significant new 
ground has been covered to assure a system that is fully 
compliant. 

• Network hardware and software for a distributed system 
have been specified to meet the required AIS access and 
controls requirements. 

• The capability to review input data and to provide virus 
checking prior to transfer to the main FADS has been 
implemented via a controlled external interface. 

• Account and password controls have been designed to 
prevent unauthorized access. 

• System activity is logged to provide an audit trail to 
assure data integrity. 


Trajectory applications are being developed to a 
standard application model. Input and output file protocols 
are standardized to allow use of common system services. 
COTS packages are specified for the menu builder, graphics 
processor, and data management system tools. 

Strict configuration management for critical and 
controlled application software has been implemented to 
assure quality and traceability results. 

FADS resource usage and system performance 
monitoring are provided to manage the FD process 
properly. 

Tangible Value 

The following savings will be accrued: 

• Increased productivity and efficiency have avoided a 
required increase of 50 EP (equivalent person) for flight 
designer staffing. 

• A savings of $2.5M/year is anticipated for FD computer 
systems operations. 

• Consolidation and streamlining of the application 
software have resulted in an overall reduction of code. 
This reduction will decrease the required software 
maintenance effort by 7 EP. 

• The FADS training environment for the associated MCC 
operators will reduce the simulation requirements placed 
on the MCC and support facilities. 

• As originally planned in 1989, the project was completed 
in FY92 and was on schedule and within budget. 

Considerable efficiency in the FD process, production error 
elimination, improved software manageability, and user 
satisfaction are expected. 
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Abstract 

The real-time data system (RTDS) project is in its 
seventh year of operations within the Mission Operations 
Directorate (MOD) at JSC. RTDS continues to lead by 
example in the introduction of new technologies to the 
dynamic environment of Space Shuttle Mission Control 
Center (MCC) operations. RTDS also continues to 
sponsor a number of projects in the form of funding, 
manpower, and a development platform that allows for 
rapidly developed prototypes to be introduced into MCC 
operations on a noninterference basis. Many of the 
projects that RTDS has sponsored over the years have 
resulted in significant cost reduction and improvements in 
MCC operations efficiency. In this report we will 
summarize the highlights of RTDS accomplishments in 
1992 and the current projects being worked in 1993. 

Introduction 

In the past year, significant changes have been made 
in the plans for the future of manned spacecraft control 
center development, plans that are affecting the future of 
the RTDS project. With the completion of the new Space 
Station Control Center (SSCC) (building 30S), plans were 
begun immediately to implement a new architecture for 
the new control center that could accommodate modern- 
day technology that would last for the 30-year life span of 
Space Station Freedom (SSF). The original plans for the 
SSCC called for it to act independently from the original 
MCC and for minimal communications to be possible 
between the two facilities owing to the 30-year difference 
in technologies between the two facilities. In June 1992, 
the decision was made to upgrade the MCC using the 
planned architecture for the SSCC, and this upgrade 
created what is known today as the Consolidated Control 
Center (CCC). The rationale supporting this decision 
factored in the improvement in communications between 
the two facilities and the reuse of the SSCC architecture 
in the MCC, thus showing substantive cost savings were 
possible after upgrading the MCC facility to newer, more 
sustainable technologies. 

The CCC architecture consists of consoles built from 
commercial UNIX workstations and file servers, a fiber 
optic (FDDI) network backbone, a distributed common 
front-end system that will replace the current mission 
operations computer, and commercial software 
applications that exploit today’s graphical user interface 
technologies. This will give a new, modem look and feel 
the control center that will give JSC’s control centers a 


much needed face-lift and will allow for the introduction 
of tomorrow’s technologies with a new approach to 
development and integration. 

The technologies just described show that what 
RTDS has been demonstrating was possible for years. 

The RTDS project has played a significant role over its 
lifetime, proving that today’s technologies can meet the 
requirements of our control centers and can improve the 
efficiency and safety of Space Shuttle operations. 
Although the RTDS project has succeeded in its original 
goal of moving the control center in the direction it is 
headed today, the project also has an important goal for 
the future: to continue introducing tomorrow’s 
technologies to CCC mission operations. With NASA 
and MOD budgets being stretched to their limits, the only 
means of accomplishing control center technology 
research and development within MOD will be through 
money provided by the Research and Technology 
Objectives and Plans (RTOP) process. This is the role the 
follow-on project to RTDS intends to fulfill. We plan to 
refer to the successor of RTDS as Advanced Control 
Center Technologies (ACCT) and will be submitting 
FY94 and subsequent years funding requests using this 
project title. 

Project Objectives 

The RTDS project objectives continue to be 
consistent with those of past years. Among these are to: 

• Inexpensively introduce new technology into real-time 
Space Shuttle operations 

• Transfer applicable technology and applications into 
Space Station operations 

• Improve the quality of flight controller real-time 
decisions using applied artificial intelligence and expert 
system technologies 

• Improve the quality and efficiency of training for flight 
controllers using new technologies 

• Provide a flight controller development platform 
externally from the control center for the purpose of 
exposing the end users of new technologies that RTDS 
explores as soon as possible, thus reducing 
development costs and discontinuing development 
quickly if it has no applicability to the particular 
discipline 

The process by which RTDS accomplishes these 
objectives has been centered around a real-time telemetry 
processing and distribution system that was developed in 
the early years of the project. This feature of the RTDS 
platform has been essential to achieving the goals of the 
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project until now. With control center development 
moving towards a platform very similar to the one 
developed by RTDS over the years, the same necessity no 
longer exists to distribute our own real-time telemetry to 
the RTDS console workstations. Also, plans are being 
worked within MOD to locate all workstation-console 
development off the flight support workstations and into 
other facilities both inside and outside of the CCC facility. 
These are key factors for the change in project focus as 
the project transitions from the RTDS project to the 
ACCT project. 

Several RTDS 1993 projects focus on planning for 
the change from providing our own telemetry distribution 
system to becoming a recipient of the new CCC telemetry 
distribution system. The first of these is the Gateway 
project, which is being managed and developed by RTDS 
personnel with support from Computer Sciences 
Corporation contractors. Gateway is developing an 
automated information security bridge between the level 3 
CCC networks and the external, level 1 JSC information 
network (JIN). This will allow real-time CCC telemetry 
to be distributed around the Center to any building that 
has access to the JIN, and will allow limited authorized 
access from the JIN into the CCC networks. The second 
project, referred to as common data interface, is 
transferring the lessons learned from the RTDS approach 
to data distribution and acquisition to Loral contractors 
supporting the CCC implementation of telemetry 
acquisition. The final step for leaving the RTDS 
telemetry processing system will come towards the end of 
1993, when the project will install several more 
workstations into the MCC side of building 30 on the 
RTDS network and will connect the RTDS network to the 
existing early commercial off-the-shelf (COTS) platform 
network that runs between the SSCC and the MCC. This 
last installation of RTDS-provided workstations will 
support many of this year’s RTDS applications and will 
act as a transition platform for the Shuttle workstation 
software to be converted to the CCC platform. This is 
being presented to MOD management as an 
MCC-to-CCC workstation transition plan and is currently 
being reviewed by the various flight control organizations 
in MOD. 

FY 92 Accomplishments 

The following summarizes the highlights of RTDS 
accomplishments in FY92. RTDS provides support and 
services to many organizations both inside and outside 
MOD in addition to its role as developer of new 
applications and technologies. RTDS also acted as MCC 
VIP host to a number of visitors during 1992, including 
the NATO AGARD committee (4/92), the Navy F-16 AI 
researchers (8/92), and the NASA Administrator Dan 
Goldin (9/92). What follows are the most significant 
successes for the past year of the project. (Note: The 
associated NASA photo number is listed with the project 
title in parentheses.) 


Flight Director Weather System (FDWS) (S92 
47203, S92 47200) 

At the request of the flight director’s office, the 
FDWS was developed to provide automated, real-time 
weather information at the flight director console in the 
main flight control room. A key element of safe and 
efficient conduct of Shuttle missions is an awareness of 
and a response to weather conditions at the primary 
landing sites, Kennedy Space Center, Florida; Edwards 
Air Force Base, California; and White Sands Missile Test 
Range, New Mexico. Prior to FDWS, the primary source 
of weather information for the flight director was through 
an audio voice link with weather office personnel. This 
required that the flight director absorb data by listening 
and jotting down sets of numbers describing wind 
directions, speeds, and runway designators. During 
periods such as prelaunch and deorbit preparation (when 
the flight director is occupied with many tasks), this form 
of data transmission was deemed unacceptably slow and 
distracting. The FDWS is now fully operational and is 
supporting all Space Shuttle missions. It has proved to be 
of great benefit for “situation at a glance” and history 
information that had been unavailable prior to its 
deployment. Its direct, simple set of displays and easy-to- 
use configuration selection have allowed it to be easily 
integrated into the flight director’s regimen. The ready 
acceptance and continued use of the FDWS are the best 
testimonials to its success, and it now contributes to safer 
and more effective missions. 

Remote Manipulator System (RMS) Position 
Monitor (S92 47198, S92 47197) 

The RMS position monitor application represents the 
first step in MCC operations towards a graphical 
presentation of the physical relationship between the 
Shuttle, the RMS, and the payload that is attached to the 
RMS. This expert system makes significant progress in 
presenting telemetry to the flight controller in a manner 
that is much more meaningful than the tabular 
information presented on the current console hardware in 
the MCC. The RMS operator in the MCC traditionally 
has relied on digital presentation of RMS joint angles 
(arm, elbow, wrist) and live video downlinked by the 
crew to interpret current RMS positioning. The position 
monitor application provides pictorial views of the RMS, 
payload, and Shuttle payload bay in X, Y, Z axis views 
together with other telemetry and alert messages that can 
be arranged in four quadrants on one screen. When live 
video is unavailable, the RMS position monitor 
application often is used as a substitute on NASA Select 
TV to give the audience a picture of current onboard 
activities in real time. 

The position monitor application has supported all 
1992 missions that included RMS operations. Highlights 
included Space Transportation System (STS)-49, which 
featured a three-crewmember extravehicular activity 
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(EVA) in conjunction with RMS/Intellsat operations. 
STS-46 saw the RMS used to deploy the Eureca-1 
satellite. Each new mission that requires that payloads be 
maneuvered by the RMS has a graphical model of the 
payload developed in the RMS flight planning system, 
which then provides the model of the payload used within 
the position monitor. The position monitor application is 
currently undergoing an upgrade to a Silicon Graphics 
surface model representation of the Shuttle, RMS, and 
payloads that will bring state-of-the-art, real-time 
graphics technology to MCC operations. 

Playback Trainer (PBT) (S92 47180) 

The PBT is a training facility developed for flight 
controller training in the Space Shuttle Program. Hie 
PBT was rapidly developed by reusing already 
established RTDS hardware and software to allow three 
DEC workstations to emulate green console displays and 
event indicator light panels. A series of Shuttle mission 
simulator (SMS) sessions was run to allow RTDS 
personnel to record a pre-scripted set of nominal and 
failure signatures for a variety of flight control 
disciplines. These recorded failure signatures were then 
organized into a set of lessons for each flight control 
discipline that is targeted to use this trainer. The intent is 
to off-load failure recognition type training objectives to a 
facility outside the expensive integrated MCC-SMS 
environment. Prior to the PBT, all training objectives 
required for flight controller certification had to occur in 
the integrated environment because no other facility 
existed to accomplish this aspect of each controller’s 
training. The PBT is now operational in most of the 
targeted disciplines with a few recording sessions 
required for the remaining disciplines. 

Booster Expert System (S92 47190, S92 47202) 

The booster expert system continued operational 
flight support on the RTDS system in 1992. The series of 
displays that comprises this application has been 
formatted to present as much data in the most meaningful 
format possible. The system combines tabular data with 
plotted data and takes advantage of the color capabilities 
of the workstation to present limit violations. The booster 
application is the most flight tested of all RTDS 
applications, and support from RTDS is considered an 
essential backup system to the MOC and consoles. 
Another opportunity arose during the STS-50 ascent 
phase where the MOC lost some of the key booster 
computations and RTDS was able to act in place of the 
MOC for several minutes during ascent. These 
occurrences are not as infrequent as most people would 
like to believe. 

The booster discipline is pressing ahead in its goal of 
becoming the first console position to operate completely 
from workstations. Within the next few months, the 
booster expert system will place a total of five 


workstations behind the multipurpose support room 
(MPSR) consoles (3 Suns and 2 DECs provided by 
RTDS) and will begin supporting simulations in the 
MPSR from a workstation-only configuration. After a 
simulation test period, a flight-following period, and, 
eventually, flight support from this configuration in the 
MPSR, we intend to replace the flight control room (FCR) 
console with a CCC workstation console configuration in 
1994. Because the FCR console is shared by both the 
booster and payload data and retrieval system (PDRS) 
disciplines, the PDRS (RMS) console operators are 
making the same plans to be ready to operate from the 
same CCC console configuration in 1994. 

Fuel Cell Monitoring System (FCMS) and Bus 
Loss Smart System (BLSS) (S92 47192, S92 
47193) 

The FCMS and BLSS applications are being 
developed using Gensym’s G2 product and will complete 
the operational application in March 1993. These 
applications debut expert system technology at the 
electrical power system MPSR console position. The 
application represents a series of graphical displays that 
are organized in a hierarchy of information presentation 
and that provide real-time data via RTDS. The highest 
level display shows a pictorial representation of the 
Shuttle electrical distribution system. This display is fed 
by each of three separate displays that depict each fuel 
cell schematic. The two applications are tied together 
such that a fault in a particular fuel cell, which affects its 
ability to provide power to the main direct current bus 
associated with it, will be reflected in the bus loss series 
of displays. An early attempt at incorporating rules that 
reflect crew procedure malfunction flow diagrams has 
also been incorporated to assist the operator in assessing 
the impacts of any particular bus failure. 

Procedural Reasoning System (PRS) (S92 

47186) 

The PRS operational evaluation project is running on 
schedule, with completion anticipated in April 1993. At 
that time, the SRI International and Australian AI Institute 
project team will meet at JSC to perform demonstrations 
of the system running against flight controller trainer 
simulator malfunction cases (and possibly RTDS data). 
The demonstrations will be performed on RTDS-provided 
workstations. The final report, which will describe the 
suitability of this technology to MCC-related tasks, will 
be provided shortly thereafter. 

Recent efforts have demonstrated the robustness of 
the PRS inference engine against MOD-provided Shuttle 
orbital maneuvering system/reaction control system 
(OMS/RCS) malfunction cases. The current version of 
PRS handles all of the malfunctions, appropriately using 
the OMS/RCS knowledge base developed directly by 
PROP flight controllers. This knowledge base has been 
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improved recently to cope with most of the fault diagnosis 
and isolation activities anticipated for the system, and it is 
being further improved to handle the fault-recovery tasks 
necessary to bring redundant systems on-line. Recent 
work also has focused on the design of a run-time user 
interface that provides the user with a real-time status of 
PRS activities, permits the user to control system goals 
and behaviors, and enables the user to perform 
hypothetical reasoning. 

Upon successful completion of this project, it is 
expected that MOD will request purchase through 
appropriate channels of a commercial version of the PRS 
inference engine and user interface. 

VISTA 

The VISTA project also is running on schedule, with 
anticipated completion in April 1993. At that time, the 
Rockwell Palo Alto Laboratory (RPAL) team will meet at 
JSC to perform demonstrations of the project ideas on 
RTDS-provided workstations. 

The project intends to demonstrate the feasibility of 
applying decision-theoretic reasoning techniques to the 
problem of managing flight controller displays. At the 
same time, the project is demonstrating the feasibility of 
applying belief networks to the problem of monitoring 
and diagnosing the performance of Orbiter systems under 
uncertainty (including missing data). The PROP group is 
building workstation data displays for VISTA to control, 
through collaboration with the workstation window 
manager, at various levels of granularity. The RPAL 
group continues to improve display management ideas 
while establishing an interprocess communication 
protocol. Additionally, RPAL and PROP continue to 
collaborate on the development and improvement of 
belief network models for various OMS operations 
contexts. 

Procurement of the Hugin belief network reasoning 
system, which will provide the inference engine for the 
reasoning system, has been completed and the product has 
been delivered and installed on the appropriate RTDS 
workstations. Procurement of the additional COTS tools 
has been completed at RPAL, and these tools are being 
used for software and interdisplay communication 
protocol development. 

IDEA - INCO DataCOMM Expert Application 

IDEA is an expert application that performs flight 
recorder logging. This application was specifically built 
to reduce the number of man-hours required to monitor 
and log Shuttle recorder information. With IDEA 
performing recorder logging, the instrumentation officer 
would perform commanding of recorders. The 
application emulates the recorder management displays 
and associates each recorder bit with its Greenwich mean 
time. In this manner, the application is cognizant of the 
data on the recorders. The application monitors the 


quality of data provided by the RTDS. The quality is 
actually the number of frames per second that the RTDS 
telemetry processor is receiving. During acquisition of 
signal (AOS), the quality should score 100. The quality 
should be less than 100 when the data quality is degraded. 
Whenever the quality is not 100 for 5 or more seconds, 
IDEA records these data as loss of signal (LOS) by 
coloring the recorder bit red and by creating an LOS list. 
The application keeps track of LOS, AOS, and playback 
lists. AOS recorder bits are colored black. All recorder 
lists are printed to UNIX files as an archive. 

PILOT - Workstation Process Monitor 

The PILOT and autopilot applications are being 
developed with Gensym’s G2 product to monitor the 
RTDS telemetry SEND and RECEIVE processes that are 
resident on the workstations that are distributing data and 
receiving data across the RTDS network. The autopilot 
software is resident on all client RTDS workstations; this 
software may act in either a send/receive mode. The 
PILOT application operates singularly at the RTDS 
operations management workstation, which presents to 
the RTDS operator a graphical presentation of the RTDS 
client and server workstations in a hierarchy view. 

PILOT tracks the client workstations send/receive 
processes and notifies the operator of problems at a 
particular console workstation after which the operator 
has the option of clicking on an icon of that workstation 
to bring up a window that will show activities on that 
node. The autopilots running on each client workstation 
have the ability to determine when a particular send/ 
receive process has gone bad, has dropped data, or is no 
longer receiving data across the network; the autopilots 
can take action on their own to kill the bad process and 
restart a new process to regain normal send/receive 
processing. 

PILOT debuted during the last Shuttle mission, 
STS-54. The RTDS operations staff was provided with 
opportunities to recommend improvements in user 
interface and functionality. The autopilot application has 
been in use since STS-47, and the application continues to 
be improved with each flight. Once these applications 
have reached an operational support capability, they will 
be demonstrated to the control center workstation LAN 
[local area network] controller operators, who will 
manage the operational workstations, to determine further 
development that could eventually be used in the 
management of the CCC console workstations. 

Office MPSR (S92 47181) 

The office MPSR project plans to explore the 
potential of running UNIX, X-Window applications 
natively on a UNIX workstation but also of presenting the 
application on a personal computer (PC) class computer. 
This project has the potential of allowing an inexpensive 
means of monitoring control center applications, with 
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real-time data, from flight controller office PCs. In 1992, 
commercial software was purchased that is required to be 
running on the PC to communicate to a UNIX 
workstation. Several products were evaluated and 31 
licenses of Hummingbird Communication’s HCL-eXceed 
X-server software were purchased by RTDS. In addition, 
Locus Computing Corporation’s TCP/IP for DOS product 
was required to allow the PC to process TCP/IP network 
protocols between the UNIX workstation and the PC. 

The end result is the PC can act as an X-server that 
processes a client application’s windows locally at the PC 
together with the real-time data RTDS provides over the 
JIN. The booster and maintenance management and 
control system disciplines currently make regular use of 
this function for a combination of SIM and flight- 
following opportunities for training in the office. No 
communication is provided between the office and actual 
MPSR support personnel, so no direct involvement of 
control center activities takes place in the office. In 1993, 
RTDS will bring on line the remaining licenses for the 
remaining Systems Division flight control disciplines. 

1993 Activities 

A primary objective of 1993 RTDS activities is to 
begin new development in the console disciplines that 
have not had an opportunity in the past to be involved 
with RTDS. To accomplish this, several 1992 activities 
were considered completed and the RTDS developers 
were moved over to new tasks. These new tasks include 
the completion of FDWS, PBT, and RMS position 
monitor, thus allowing for new development in the EVA 
and electrical, emergency, and consumables manager 
(EECOM) disciplines. RTDS continues to follow the 
philosophy of bringing new development to an 
operational capability and then transitioning it to 
appropriate sustaining personnel outside the project staff. 

Several of the previously mentioned 1992 
applications are continuing development into 1993. They 
include: FCMS and BLSS, PILOT, PRS, VISTA, artd 
office MPSR. These applications will not be mentioned 
here again. Refer to the previous text for future 
development planned on these tasks. 

EVA Expert System 

The EVA expert system project was started in 
November 1992 and will bring the EVA flight control 
operations into the workstation development activity that 
has been ongoing in the other disciplines for years. This 
application is targeted at improving all aspects of 
monitoring EVA crewmember extravehicular mobility 
unit (EMU) suit data. The current EVA real-time data 
system processes all crewmember biomedical data 
together with suit data into one long bit stream that must 
be deciphered by the cuaentsy stem, calibrated, and 
presented in -25 different parameters for each suit. The 
development planned for the EVA expert system 


application will acquire data via RTDS, parse the data, 
and apply pseudo-measurement stimulation identifications 
to each of the 25 parameters before presenting unique 
parameters for each suit to the graphical user interface. A 
combination of tabular, plotted, and schematical views of 
EMU suit data is planned for 1993 development. This 
project has the ambitious goal to provide EVA flight 
controllers with a complete application in time for the 
start of the STS-61/Hubble space telescope (HST) revisit 
mission simulations (September 1993). It is anticipated 
that this application will provide the EVA operators with 
a chance to perform flight-following of the HST EVA 
activities from the CCC operations control room 
workstations during the flight planned for December 
1993. 

The EMU data processing module of this application 
was used for the first time in the MCC during the EVA on 
STS-54. The goal during STS-54 was to acquire the 
EMU suit data via RTDS and to verify its correctness 
against the current EVA flight data system that are 
residing on an HP-9000 computer. Postflight validation 
of the RTDS version of the EMU data is ongoing. During 
the flight, EVA section management, flight surgeons, and 
EVA flight controllers all had an opportunity to become 
familiar with the project and to make inputs for future 
development. 

EECOM Expert System 

The EECOM expert system project will be the first 
introduction of RTDS data and expert system 
development for the EECOM flight control discipline. 
This application will reflect EECOM flight control 
requirements for the display design and development that 
are planned for use in the CCC in December 1994. These 
displays will combine tabular, plotted, and schematical 
views of the data to generate follow-on requirements for 
data presentation in a more efficient manner. At the 
beginning of this project development, Talarian’s 
RTworks product was selected as the graphical user 
interface builder tool and rule development environment. 
Recently, the CCC selected a different graphical display 
builder tool, Sammi, which was developed by a local 
Houston company, Kinesix. The remaining work for the 
EECOM application will be done using this Sammi 
product. 

This project is expected to provide a lead-in 
application for follow-on work in FY94 as part of a joint 
project with the Control Center Systems Branch (DJ2). A 
joint Code C Ops Cost Reduction Proposal was submitted 
by DJ2/Janet Lauritsen and RTDS/Linda Perrine to 
explore the Jet Propulsion Laboratory’s (JPL’s) SELMON 
tool. This project will be referred to as DREMON, and it 
will evaluate the selective monitoring and trend analysis 
capabilities of SELMON. JPL is expected to provide 
development support for three different applications to be 
integrated with SELMON: the SSF thermal control 
system automation project, the EECOM expert system, 
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and the SSF environmental control and life support 
system (ECLSS) advanced automation project. 

Stripchart Pattern Recognition 

The stripchart pattern recognition project plans to 
explore the applicability of neural network theories to the 
recognition of standard stripchart signatures that are seen 
in a variety of disciplines. The most distinctive signatures 
are provided by the alternating current (AC) powered 
equipment’s motor start-up currents. Most AC-powered 
Shuttle hardware have individual characteristic signatures 
that flight controllers can identify, with practice, as 
nominal or off-nominal start-up currents. This analysis of 
paper plotted data is the ground’s best insight to the 
anomalous operations of this equipment. This means of 
analysis has been critical in diagnosing frequent problems 
with the waste containment system urine fan separators on 
several recent Shuttle missions. The approach this project 
will take is to use distinctive electrical signatures to 
determine the applicability of neural network technology 
to real-time telemetry monitoring and then to expand the 
scope of the project to other disciplines that require 
stripchart recorders to monitor high sample rate data 
(> 1 sample/sec). 

Neural networks have been applied very successfully 
in the medical field to monitor electrocardiograms and 
other biomedical monitoring equipment. It remains 
questionable, however, whether the high sample rate data 
processing of the workstation coupled with the detailed 
signature analysis done by artificial neural networks will 
allow for keeping up with all parameters in “real time.” 

Cooperative Expert Systems (COOPES) 

The COOPES project will be a cooperative venture 
with the Information Systems Directorate McDonnell 
Douglas contractors. This project has been waiting to get 
started since it requires the completion of the BLSS G2 
application mentioned previously. The McDonnell 
Douglas COOPES team has spent significant time doing 
prototype demonstrations of cooperating expert systems, 
however, and has not had the opportunity to demonstrate 
an approach in the control center environment. RTDS 
intends to give the team that opportunity this year, 
however, because the work will need some customization 
for operating in the real-time environment of the MCC. 
The BLSS application will be used as the initiator 
application for communicating bus failure information to 
the other flight control positions via the networked RTDS 
workstations. Currently, bus loss information must be 
communicated verbally over the communication loops, 
which often results in misunderstood information or in 
operators not hearing the information at all. Other areas 
that will be explored as time permits are communication 
of multiplexer/demultiplexer and dedicated signal 
conditioner failures. It is an instrument and 
communication officer’s responsibility to communicate 


this information to the rest of the flight control room and 
is also currently done verbally. 

CCC Development Support 

The RTDS project was approached in August 1992 to 
provide assistance to the operations support contractor, 
Loral, to apply lessons learned from past RTDS 
experience to the development of the CCC being done by 
Loral. Three areas were targeted for planned support 
from RTDS during FY93; they are: 

• Common Data Interface - Applying RTDS experience 
for data distribution, acquisition, and application 
programming interface. 

• Expert System Server Study - Making use of RTDS 
expert system development experience and hardware to 
determine efficient placement of licenses in the CCC. 
We also are assisting in the selection of the CCC 
standard expert system development tool (COTS), and 
we have done research on several products. 

• Global versus Local Limit Sensing - Making use of 
RTDS application development experience and 
hardware to prototype an appropriate transition of 
centralized MOC limit sensing to the distributed, 
networked environment of the CCC. RTDS has the 
resources (people and hardware) to provide this 
support. 

Work is ongoing in the first two areas, and work in 
the third area will be started shortly. 

CCC/JIN Gateway Project 

This project was originated at the request of MOD 
management to build a bridge between the Mission 
Control Center upgrade (MCCU) networks and the RTDS 
network in the MCC. The purpose was to move 
development off of the operational flight support 
workstations and onto a less secure, more open 
development platform that RTDS provided. With this 
past year’s change of plans for the future of control center 
development, the MCCU platform quickly became the 
wrong platform on which to expend our development 
efforts. We negotiated with MOD management to rethink 
this plan and instead build a gateway for the future that 
would not only allow development to occur off of the 
CCC operational workstations, but also allow 
development to occur outside the control center facility. 
This became the CCC/JIN gateway, and we are currently 
in full-scale development of this capability. Phase 1 of 
this project, which is targeted for completion this summer, 
will install a DEC workstation in the old transitional flight 
control room along with a network router that will force 
communications between the level 3 CCC networks and 
the level 1 JIN to be one-way only. This will provide the 
long-term capability that RTDS has provided in the past 
of distributing real-time telemetry to office buildings 
around site as well as to other locations, such as Ames 
Research Center. Phase 2 of the project will require more 
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detailed requirements and design to allow limited 
authorized access from the JIN into the CCC networks. 
We will not be able to accomplish Phase 2 during FY93 
and will need to look to MOD for continued funding of 
the project next year to accomplish the path into the CCC. 

Conclusions 

In addition to RTDS, there are many efforts ongoing 
at JSC to upgrade old facilities to today’s technologies. 
Most, if not all of these technologies, are necessary to 
enable manned spaceflight operations to move into the 
next century and to pursue a "better, faster, and cheaper” 
approach. Often these words are placed in reverse order 
when confronted with the realities that NASA’s budget 
presents today. Perhaps what really needs change is the 
mind-set within NASA of sacrificing the move to new 
technologies as a means of saving money. In the long 
run, this will turn out to be the more expensive route to 
our goals. To quote our Administrator from a speech he 
made to the Association of Space Explorers: "The 
technology generated from space exploration is one of the 
highest yielding investments in our future this country can 
make.” This statement must apply to our control center 
technology development with the same priority it applies 
to the vehicles we will monitor from these facilities. 

The RTDS project has succeeded in its original 
endeavor to demonstrate that new technologies can be 
used to meet the demanding requirements of manned 
space flight control center training and operations. 

RTDS — and the people who have been associated with 
the project over its 7-year life span — is arguably the key 
factor in showing a new direction for the future of control 
centers at JSC. The $9M investment that RTDS 


represents should appear to be money well spent and a 
positive reflection on the RTOP process that must 
continue into NASA’s future. 

In FY94, under the new project title of ACCT, MOD 
plans to continue the successful efforts begun in the 
RTDS project. The new project will concentrate on 
keeping abreast of industry advances in technologies that 
have the potential for applicability in the control center 
environment. As stated earlier, MOD budget does not 
allow for the luxury of looking at new possible 
technologies, of determining how to integrate them, and 
of at the same time managing Space Shuttle and SSF day- 
to-day operations. Therefore, if NASA and MOD intend 
to keep pace with new technologies and to explore them 
as inexpensively as possible, a project such as ACCT will 
be a necessary and an integral part of MOD activities for 
many years to come. 
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S92-47203 Flight Director Weather System 



S92-47200 Flight Director Weather System 
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S92-47198 Remote Manipulator System (RMS) Position Monitor 



S92-47197 Remote Manipulator System (RMS) Position Monitor 
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S92-47192 Fuel Cell Monitoring System (FCMS) ans Bus Loss Smart System (BLSS) 
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S92-47193 Fuel Cell Monitoring System (FCMS) ans Bus Loss Smart System (BLSS) 
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Abstract 

A system that will provide real-time failure 
management to Space Station Freedom and Shuttle orbital 
operations is described in this paper. The system’s use of a 
simplified form of model-based reasoning qualifies it as an 
advanced automation system. Our system differs from most 
such systems, however, in that it has been designed from the 
outset to meet two sets of requirements. 

The first requirement is that the system must provide a 
useful increment to the fault management capabilities of the 
JSC Control Center Complex (CCC) fault detection 
management system. The second requirement is that the 
system must satisfy CCC operational environment 
constraints such as cost, computer resource requirements, 
and verification and validation. The need to meet both 
requirement sets presents a much greater design challenge 
than would be the case had functionality been the sole 
design consideration. In this paper, we will present an 
overview of the choice of technology by discussing aspects 
of our choice and the process for migrating the technology 
into the CCC. 

Introduction 

In this paper, we will provide an overview of the underlying 
technology and design of extended real-time [failure 
environment analysis tool] FEAT (ERF) within the context 
of its migration to the CCC. The fault detection and 
identification (FDI) problem will be described together with 
constraints imposed upon the developers — both those 
imposed because of good software engineering and those 
imposed by the nature of the environment. The approach 
we took will be addressed next; and the choice of 
technology, the algorithms developed, and the possible 
extensions and adjuncts to those algorithms are also 
examined. The solution settled on will be presented as well 
as its current status and general comments. We will end the 
paper with some concluding remarks. 

Problem Description 

Fault detection and management (FDM), which is a 
major mission controller area of responsibility, may be 
divided into two phases: FDI and recovery of some part of 
the lost capability. Immediate action that is required to safe 
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the system from further failure propagation is included, 
when appropriate, in the FDI phase. 

The FDI Task 

An analysis of the FDM process 1 showed that the FDI 
phase primarily consists of drawing logical conclusions 
about the cause of an observed problem from facts about the 
monitored system and telemetry data. The recovery process 
proved to be much more complex, however. 

Although, in principle, FDI is a straightforward logical 
task, several factors can combine to make it very 
challenging. First, space vehicle systems have become 
extremely complex. Such systems consist of a very large 
number of component elements, which may interact in a 
variety of ways depending on the current system state. 
Furthermore, some interactions may be obscure and rare. 
Second, a very large number of parameters must be 
monitored. Third, the controller is usually under some 
degree of time pressure; thus, in many cases it is not 
practical to run traces through functional schematics and 
look up data in handbooks or other reference material. 

The challenge of the FDI task gives rise to several 
concerns. For example, the controller may not remember 
the complete set of relevant facts, consider all applicable 
data, or identify the correct procedure to apply. 

It was seen that some form of “controller’s associate” 
could materially assist controllers working an FDM 
problem. Such an associate should not attempt to automate 
the controller. As a minimum, a controller’s associate 
should assume the chores of storing and recalling facts 
about the failure behavior of the monitored system and of 
accessing real-time data to draw conclusions about possible 
system failures from those facts. ERF meets these 
requirements. 

Constraints 

Flight-critical software applications lie outside the 
scope of a research lab. Real-world constraints must be 
considered, among which are: robust interfaces to real-time 
data must be provided, missing and noisy sensor data must 
be dealt with, multiple problems must be queued, and 
analyses must be interrupted and resumed. Real-world 
applications also need to be considered, such as end-user 
constraints and implementation requirements. 
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Controller concerns imposed a number of constraints 
on the design of ERF. ERF’s user requirements are either 
an explicit subset of the broad user requirement 2 or are 
derived therefrom. These include requirements for 

• Compatibility with proven real-time mission support 
operations 

• Prompt solution response 

• Positive operator control at all times 

• Generic FDI capability 

Any automated system designed for real-time mission 
operations must support the process currently used by 
human controllers. Shifting part of a controller’s 
responsibility to a computer means that the computer must 
play its part in a human/computer team; it cannot be a solo 
player. 3 

Accurate identification of the failure at hand is a 
prerequisite for dealing with critical situations. This means 
that, to be useful when it is really needed, a controller 
support system must take no longer to provide a solution 
than the time taken by an experienced controller. ERF is 
required to identify failures and to assess their impacts 
within 5 minutes on average, 6 minutes in the worst case. 

Just as a human team player must take orders, ERF 
must always be directly controllable by the operator. This 
means that ERF must keep the controller informed of its 
intentions and allow the controller to redirect it, or to halt it 
if necessary, at any time. 

Because failure identification is in principle a generic 
process, ERF is required to support FDI for all Space 
Station onboard systems for which its basic knowledge 
representation scheme is appropriate. Similarly, ERF must 
be able to support Shuttle on-orbit operations for systems 
that have been modeled in ERF-compatible form. 

Any development of an application whose target is 
within the real, operational world needs to satisfy such real- 
world constraints as cost ceilings, resource allocation limits, 
and fast algorithm performance. Sometimes data will be 
noisy and/or missing. Interfaces must exist with other CCC 
systems (status and control, data base functions, the data 
streams, etc.). Choice of platform, development 
methodology, and language will be made by the control 
center developers, not by the technologists. The application 
and the models that an application uses must be susceptible 
to verification, validation, and maintenance. 

In the case of the CCC, the constraints included the use 
of Ada for all new code, minimal cost, working within the 
constraints of the development environment for the CCC, 
following methodological guidelines for formal software 
development, and formal reviews. 

Approach 

Technology Description 

ERF is fundamentally built on a bi-valued model 
representation. The models are causal networks of failure 
that are represented as directed graphs and are automatically 
configured, via telemetry and knowledge of system 


degradation, to represent the system’s observable state. 
These models are then operated to infer information about 
commonality among annunciated out-of-limit or alarm 
conditions, about what could have been the cause(s) of these 
annunciations, and about where these effects might 
propagate. 

The FEAT, which is built by the JSC Intelligent 
Systems Branch, computes transitive closure for the given 
model and displays the results of queries graphically . 4A6 
ERF is a layer of software on top of FEAT that extends 
ERF capabilities. Specifically, ERF sequences queries to 
FEAT in a manner that is similar to the way in which a 
controller might use FEAT to analyze either real-time data 
or hypothetical data. The results are displayed on FEAT 
displays and/or on displays that are external to FEAT. 

Currently, FEAT runs on both Macintosh and Unix 
platforms. 4,5 A companion product, the Digraph Editor, 4 
provides an environment that aids in constructing failure 
models for FEAT, although other tools that adhere to the 
PICT standard can produce working digraphs for FEAT. 
Both products are written in C and are available for the 
Macintosh through COSMIC. The Unix version has just 
been submitted to the Space Station Freedom Program’s 
Technical and Management Information System and is now 
available to the Space Station Program. Eventually, this 
version will be available to all users through COSMIC as 
well. 

Rationale 

ERF technology was selected because it provides the 
required functionality and satisfies the following 
constraints: 

• It uses relational failure models of the systems being 
analyzed. 

• The digraph failure models, which are documented via a 
graphical representation, are more easily maintainable 
than are equivalent text representations. 

• It uses a standard mathematical technique for computing 
reachability (connectivity) analyses; i.e., transitive 
closure. 

• In addition, it uses heuristic knowledge about how to 
diagnose failures in physical systems. 

ERF allows FDI applications to be developed without 
the system operational failure experience heretofore thought 
essential for developing such systems. On the basis of 
design-derived knowledge, the diagraph failure model 
describes how a system must fail. ERF algorithms provide 
a methodology for interpreting the model based on sensor 
data. Because the sensor interpretation algorithms are 
model independent, ERF will work for any system for 
which a FEAT-compatible failure model is provided. 

Results 

In this section we will summarize only at a conceptual 
level the analysis algorithms that ERF implements. At the 
highest level, these algorithms are commonality assessment, 
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failure identification, and impact assessment. We will also 
describe the results obtained during 1992. 

ERF Core Analysis Algorithms 

The commonality assessment algorithm uses a digraph 
to determine if there are paths between components that 
have failure indications. If paths exist and there are no 
dependencies that could impede failure propagation, we can 
assert that one of the sensors is “primary” and that the other 
sensors downstream of it are “secondary.” 

Failure identification takes the announced conditions, 
retrieves additional state information, and categorizes the 
observables in the model into one of three states: good, bad, 
or unknown. From this, ERF builds an initial set of possible 
causes. This set is pruned using knowledge about the 
known good components and digraph modeling artifacts to 
narrow the space of possible causes. Any remaining 
unknown observables in the model are then presented to the 
controller. If additional information can be obtained, the 
analysis is refined. An early version of this algorithm is 
detailed in Ref. 7. 

The impact assessment function takes these possible 
causes and predicts their respective effects on the system. 
ERF will annunciate lost redundancies, where a failure may 
propagate if the other leg in the redundancy is lost, and new 
susceptibilities for critical functions (i.e., new single- and 
dual-failure sources). 

Status 

ERF is a subsystem of the CCC fault detection and 
management system. We held a preliminary design review 
in March 1992.' Preliminary design inspection is scheduled 
for February 1993 to align the design with the new CCC 
architecture. The analysis algorithms will be available in 
the CCC advanced automation test-bed in June 1993. 

An informal prototype for algorithm development and 
detail design activities currently exists. At the end of 1992, 
this protytype consisted of two separately running 
processes — the graphical user interface and the analysis 
routines. While far from being the system that will be 
delivered to the CCC, the current informal prototype 
demonstrates: 

* Basic analysis functions (commonality, failure 
assessment, and impact assessment) 

* Use of FEAT displays for analysis presentation 

* Use of additional displays built outside of FEAT for 
results presentation 

Conclusions 

ERF is an application that will aid a mission controller 
in identifying the cause(s) and subsequent effects) of 
observed failure symptoms in a monitored system. It is a 
layer of software built upon the FEAT provided by the 
Intelligent Systems Branch at JSC. This additional layer 
provides: (1) automated fault identification and effects 


analysis algorithms that are model independent, (2) hooks 
for alternate model representations and alternate analysis 
engines, (3) interfaces to real-time data, and (4) automated 
problem management functions. 

ERF uses advanced automation techniques and 
provides automated FDI analysis for any system that can be 
modeled as a causal network of failure modes. As the 
controllers identify additional candidate functions for 
automation, there will be opportunities for ERF capabilities 
to expand and/or for ERF to work with other applications. 
ERF has been designed to provide hooks for swap-ping 
underlying representations and analysis engines, for 
incorporating more advanced analysis algorithms, and for 
communicating with other applications. 

We intend to explore alternate analysis engines and 
representations, communication with other applications, the 
development of more sophisticated FDI algorithms, and the 
recovery problem. Some of these efforts have already 
started, while other efforts are still on the horizon. 
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Abstract 

In the beginning of FY92, the development organiza- 
tions of the Mission Operations Directorate (MOD) at 
JSC were poised to begin two major projects: the Space 
Station Control Center (SSCC) and the refurbishment of 
the telemetry processing area of the Space Shuttle 
Mission Control Center (MCC). A study team established 
that a common front-end concept could be used and that it 
could reduce development costs for both projects. A 
standard processor was defined to support most of the 
front-end functions of both control centers and to support 
a consolidation of control positions that effectively 
reduces operations cost. In this paper, we will define that 
common concept and describe the progress that has been 
made in the development of the Consolidated Communi- 
cations Facility (CCF) during the past year. 

Introduction 

In preparation for ground support of the upcoming 
Space Station, the MOD had begun to plan to construct a 
Space Station Control Center. A building adjacent to the 
MCC was under construction and requirements had been 
written. At the same time, development efforts in the 
MCC had been refocused to replace the oldest and least 
reliable machines, those with front-end functions. A 
study team was established to determine whether there 
was a joint effort to develop a common design. It was 
hoped that such an effort would reduce both development 
and recurring costs. 

Approach 

We began the study by defining a model of the front- 
end functions. Once the functions were defined, the 
requirements were mapped against our model. A market 
survey was done to determine whether the needed 
equipment to accomplish the front-end functions was 
available in the marketplace. 

Results 

A three-layer view of the processing was produced 
and is shown in figure 1 below. 

Layer 1 is the processing that terminated the ground- 
to-ground protocol and interfaced with the external world. 
The Goddard Space Flight Center communications 
network protocol is handled in this layer, thereby isolating 
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the remainder of the control center from any changes in 
ground network. 

Layer 2 provides source-specific processing for the 
front end. This format manipulation layer does the 
specific format manipulation based on variations in 
spacecraft communications. It, in turn, isolates any 
changes in spacecraft telemetry from any other areas of 
the control center. 

The final layer, layer 3, formats the data so that the 
data can be distributed to the remainder of the control 
center. Ideally, despite the spacecraft, the format is 
identical. This allows common applications, such as 
display building programs, to use and understand the data 
independent of source. 

Each processing layer removes data formatting 
variation such that the entire front end produces a set of 
data that is identical despite its source (fig. 2). An 
application can use the data from any spacecraft without 
modifying the data to its processing code. This provides 
an excellent opportunity for duplication of several 
applications downstream of the front-end processing. 
Additionally, future support for additional spacecraft 
becomes easier. 

This model provided an excellent framework against 
which to map the requirements of the Shuttle and Space 
Station Programs. In mapping these functions, layer 1 
was designated the institutional layer. It contained the 
demultiplexers and modems that receive the data from the 
external world. Layer 1 included recording, switching, 
and routing functions. It also included processing to 
handle the ground network data that included data from 
other NASA sites, network scheduling, and network 
status data processing. Requirements for Space Station 
and Shuttle data processing revealed that the layer 1 
functions were identical for both programs. 

Layer 2 isolated most of the differences between the 
spacecraft telemetry. Space Station telemetry consists of 
consultative committee for space data systems (CCSDS) 
packets that use Reed-Solomon encoding. Its telemetry 
object lists are nonperiodic. Shuttle telemetry, which 
could require decryption, uses Interrange Instrumentation 
Group standards, TTie periodic nature of the Shuttle 
telemetry is key to validating and decommutating the 
data. It became clear in mapping the requirements for this 
layer that the two programs completely differed. If the 
unique processing could be isolated, however, it appeared 
that a synergistic approach to the front end could be 
achieved. Spacecraft-unique processing of data could be 
performed on a single type of machine. The use of a 
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single platform, even with a different configuration of 
boards, would allow a synergistic approach to the 
maintenance and operations of the machines. 

Once the data have been extracted from their 
downlink format, layer 3 provides distribution of these 
data to other areas of the control center. Development of 
a common data format provides the potential that the data 
acquisition functions used to receive data throughout the 
control center can be identical and that additional 
synergistic savings can thus be created. The code to 
perform layer 3 functions for Shuttle telemetry differs 
somewhat from that of the Space Station Program, but 
both sets of code can be easily run on the same platform. 

The allocation of control center requirements to the 
three-layer model is illustrated in figure 3. 

Correspondingly, the uplink function was mapped in 
reverse — the building outbound commands were in a 
layered fashion. The basic elements of these layers are 
given in figure 3. Once again, it is apparent that the 
functions are parallel and that the programs could benefit 
from synergism. 

The study team evaluated the requirements and did 
an initial survey of the marketplace. A straw-man 
architecture was proposed in which the front-end 
processor was a VME-based machine. Specialized boards 
to do spacecraft-unique processing were available that 
would run on such a platform. 

Results 

An estimate for a common front end for both control 
centers at JSC determined that NASA could save 15% of 
the estimated development costs and could reduce the 
maintenance staff by 30. Some savings result from the 
use of a single piece of hardware for both programs. 

Some savings are owing to the single development effort 
on common platforms that are customized for each 
program. The results of this study were used to launch 
the CCF project. This occurred approximately 1 year ago. 

Current Status 

Since that time a year ago, the requirements for a 
consolidated system have been written and the project has 
been divided into five subsystems. These are: the 
consolidated data select switch (CDSS), the consolidated 
data recording subsystem (CDRS), the front-end proces- 
sor subsystem (FEPS), the consolidated distribution 
subsystem (CDS), and the test and checkout subsystem 
(TCS). Each of these subsystems has been designed and 
procurements are in progress. A mapping of the sub- 
systems to the layered concept is shown in figure 4 below. 

The CDSS performs high-rate and low-rate data 
switching, accepts multiple data lines from external sites, 
and routes data to external sites. The low-rate data switch 
handles the majority of this work — it is currently 
specified as a 600x500 port switch. Responses to the 
request for proposal for this switch are expected soon. 


The high-rate data switch has few lines and might be 
patched rather than switched. It will not be developed until 
late in the project. 

The planned CDRS technology is borrowed from the 
television industry, which keeps commercials on cassettes. 
A robot queues the tapes automatically and plays them as 
scripted. The control center taping system is envisioned as 
two sets of robotically operated tape silos. Because 
recorders do not operate efficiently at the slow data rates of 
the control center, data will be buffered and sent to the 
recorders in bursts. The recording system is expected to be 
run with minimal operator intervention. The operator will 
be needed only to remove any tapes for permanent storage 
or to arbitrate playback capability. This approach will 
reduce operations costs — a strong theme in the 
development of the CCF. 

The FEPS contains the bulk of the processing in the 
CCF. The current design of the MCC contains several 
specialized hardware devices designed in the 1960s and 
1970s. Over the years, other systems based on more 
modem commercial off-the-shelf technologies have 
partially replaced the front-end processing capabilities, but 
these systems were never able to do so completely. The 
result is that the MCC now has hardware supporting four 
different design approaches to the telemetry processing. 
These variant hardware will be replaced with the CCF. 

The design of the CCF FEPS is based on a single 
VME-based machine. The machines will be tailored to suit 
the specifics of the spacecraft data for which they are used 
with special processing boards and software. The FEPS do 
all of the layer 2 processing. This isolation of layer 2 to a 
single processor means that the CCF could be expanded to 
handle future vehicles by changing only FEP processing. 
Additionally, FEPS provides the processing platform with 
which to create the common data format discussed in 
layer 3. Procurement for the FEPS is currently in progress. 

The TCS will run on the FEPS platform and will 
provide the ability to run test data streams through the 
system and to score the output to assure proper processing. 
The TCS will be run routinely to validate that the hardware 
and software are ready. It will also be used by maintenance 
personnel to locate problems. Development of TCS 
software is currently being done on a UNIX platform, and 
the code will be transferred to the FEP platform after FEP 
delivery. 

The CDS provides distribution of data to the 
computation and display systems throughout the control 
center complex, including the older IBM mainframes and 
the newer UNIX workstations. The CDS consists of a 
packet-based switch or a local area network (LAN) and 
assorted interfaces. One interface provides configuration 
management and status and control. Other interfaces will 
emulate current interfaces, thereby minimizing the changes 
required to the older MCC machines (to reduce risk). 
Interfaces that are not standard LAN products are hosted on 
FEP platforms to reduce hardware maintenance costs. 
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Conclusions 

By looking at ground support for a joint Space 
Station and Shuttle project, MOD has found a better and a 
cheaper way of providing a telemetry processing area. 

The definition of a front-end concept and the mapping of 
functions required by both the Shuttle and Space Station 
Programs clarified the needs of each program. From this, 
MOD was able to determine what common hardware and 
software could support both programs. Subsystems were 
defined and designs done to accommodate the needs of 
both programs, as well as to expand for future needs. The 
procurement of much of the CCF is currently in progress, 
and the entire project is expected to be complete in 1996. 

Because the format of the data output by the front 
end is common in nature for both programs, a single 


display processor can be used for either Shuttle or Space 
Station data. This common basis for front-end output 
greatly simplified consolidation of the remainder of the 
control centers for each program. From this grew the 
Control Center Complex, which is currently being 
developed. The Control Center Complex contains the 
functionality of both the Space State Control Center 
(SSCC) and the MCC, but it costs less to build and to 
maintain than each center separately. 
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Abstract 

The failure environment analysis tool (FEAT} 
application requires a fast algorithm to compute transitive 
closure of directed graphs with more than 70,000 nodes. 
The current algorithm will require days or weeks to 
perform this calculation. This report documents the initial 
evaluation of the speed and complexity of several 
alternative algorithms. Also, this report recommends 
areas for further study. 

Introduction/Background 

FEAT uses a directed graph (digraph) to represent 
system failure cause-and-effect relationships. Complex 
systems may be modeled using simple formalisms. A 
digraph used with FEAT consists of nodes representing 
failure events, edges representing causal relations 
between adjacent failures (nodes), and logical 
conjunctions between nodes. These conjunctions consist 
of logical OR connections and two-input logical AND 
connections. These digraphs may be cyclic. Reference 1 
provides a detailed description of FEAT and the digraph 
representation of system failures. 

FEAT processes system digraphs and computes 
transitive closure for the complete graph. This allows 
FEAT to provide information concerning the ultimate 
causes and effects starting at any node. Most transitive 
closure algorithms support only direct connections (such 
as OR connections in FEAT). 2 The current FEAT 
transitive closure algorithm is based on Warren’s 
modifications to WarshalPs algorithm, 3 which allows 
computation of transitive closure on a matrix of boolean 
relations. These algorithms are 0(N 3f ), where N is the 
number of nodes. 

FEAT models of more than 7,000 nodes have already 
been created. It is anticipated that models approaching 
100,000 nodes will be generated for the Space Station 
Freedom (SSF) Program. Since the existing FEAT 
algorithm takes more than 388,800 sec to compute 
transitive closure for a 7300-node model on a Sun Sparc 2 
workstation, it is clear that the computation time must be 
reduced for FEAT to be able to analyze large SSF models. 

Several approaches have been taken to develop a 
more efficient method of computing transitive closure for 
FEAT digraphs. The Z1 algorithm was developed at JSC 
as a sequential approach to computing transitive closure 
for these models by taking advantage of the AND gate 


structure in FEAT digraphs. This algorithm correctly 
solves acyclic digraphs only. A parallel computer version 
of this algorithm was developed for the multiple 
instruction, multiple data Intel hypercube and is called 
ZP. A third variant of the Z, called ZR, was developed to 
allow processing of cyclic digraphs; this variant takes 
advantage of experience acquired during the parallel 
computer development effort. A separate effort by Dave 
Iverson at Ames Research Center produced an object- 
oriented algorithm (called AMES), which computes 
transitive closure of cyclic as well as acyclic digraphs. 

The Z1 algorithm starts by performing a topological 
sort of the digraph and then processes each node in order 
from roots (nodes with no inputs) to leaves (nodes with no 
outputs). Each node is evaluated based on whether it is an 
AND node or an OR node. At each AND node, the inputs 
are computed to determine the singletons (single-point 
failures) and doubletons (pairs of failures) that affect this 
node and that are to be passed on to the downstream 
nodes. An OR node simply inherits singleton and 
doubleton lists for all nodes that reach it. The process 
continues in order until all nodes have been processed. A 
final pass is conducted to update upstream nodes with 
downstream data. Each node contains all nodes that reach 
this node and all nodes that this node reaches. 

Example 

This example illustrates how the Z1 algorithm 
computes the transitive closure of a directed graph. The 
process will be examined using the digraph in figure 1. 

Table 1 shows the adjacency for the graph in figure 1. 

Step 1: Topological Sort 

For the example digraph, the topological order for the 
nodes is A,B,C,D,E. 

Step 2: Singleton and Doubleton List Propagation 

Using the ordering from Step 1: If a node has AND 
inputs, the singleton and doubleton lists from its two 
inputs are used to compute this node’s doubletons and any 
additional singletons. 

The current node will then propagate its singleton 
and doubleton lists to each node on its output OR list. 

In the example, node A will be processed first. Since 
it has no AND inputs, it will concatenate its singleton list 
to the singleton list of node B. Node A will then 
concatenate its doubleton list to the doubleton list of node 
B (uniqueness checks are made for each singleton and 
doubleton added to each list, so that multiple listings of 
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the same node are avoided). Once node A has completed, 
node B is processed. Since node B has no AND inputs, 
its singletons and doubletons are sent to node C. 

Node C then begins processing. Since it has no 
output ORs, however, node C is complete; so control is 
passed to node D, which is also complete. 

Finally node E is processed. Node E has AND 
inputs, so it must compute its singletons and doubletons 
before propagating its information to its outputs. Using 
the singleton lists of its two inputs — nodes C and D — 
node E creates the following doubletons, which are added 
to its input OR list: (A,D), (B,D), (C,D). This 
computation is simply a cross product of the singleton 
sets of node C and node D. Again, a uniqueness check is 
performed to eliminate any repetitive information. 

Once this check is complete, the output lists are 
updated to indicate the forward reachability. For instance, 
since node A is a singleton to node C, node C is added to 
the output OR list of node A. In addition, since node A is 
a member of a doubleton pair to node E, then node E is 
added to the output AND list of node A. 

Table 2 reflects the final results for the digraph in 
figure 1. 

The ZP algorithm is designed to operate on parallel 
machines with message passing constructs and several 
powerful processors. The graph is subdivided using a 
depth first search, and each processor is assigned a 
subgraph from the digraph. Each processor then applies 
the Z1 algorithm to its subgraph. The algorithm does not 
conduct a topological sort but, rather, keeps track of 
whether the inputs to a node have been computed. A 
node is not processed until all inputs are computed. This 
effectively orders the digraph without the computational 
overhead of a separate topological sort. Messages are 
passed from a processor containing a node connected to a 
node on another processor for each edge that leaves the 
processor. The message contains all upstream 
information for the node. Each processor analyzes its 
subgraph as completely as possible and then waits for 
messages necessary to continue processing. After all 
processors complete, a final pass is made through the 
digraph that consolidates the results and updates upstream 
nodes with downstream data. The final result is the same 
as the Z1 algorithm, but it is obtained much more quickly. 

The ZR algorithm is essentially a sequential 
adaptation of the ZP algorithm. The algorithm proceeds 
until all nodes have been completed. This algorithm does 
not keep copies of all upstream doubletons at each node; 
rather, pointers to upstream AND nodes are maintained. 
AND nodes contain all upstream data. This algorithm is 
also more suitable for processing cyclic digraphs. 

The AMES algorithm takes an object-oriented 
approach to the computation of transitive closure. It does 
not use a formal sort to order data but uses an approach 
similar to that of the ZR algorithm. 


Problem Statement 

Which algorithm should be incorporated into FEAT? 
To determine the answer to this question, the performance 
of the Zl, ZP, ZR, and AMES algorithms was analyzed 
on a number of large digraph models. The results of these 
runs will be studied to determine the fastest algorithm and 
to estimate the computational complexity of the 
algorithm. This will allow a rough extrapolation of 
computation times to much larger models. 

Approach 

A collection of directed graphs was obtained for 
validation, verification, and testing of each of the 
algorithms. These graphs ranged in size from 8 to 
14,000 nodes. Most were taken directly from actual 
system models, while others were developed to include 
special digraph configurations that would rigorously 
exercise the resiliency of each of the algorithms. 

A 40 MHz Sun Sparc 2, with 24 MB of memory and 
100 MB of swap space, was used in the testing of each of 
the sequential algorithms. An Intel IPSC860 hypercube, 
with 32 processors, was used in the testing of the parallel 
algorithm. Each of the sequential programs was compiled 
on this platform, using the same gcc compiler with -O 
optimization. 

The Zl, ZR, and ZP algorithms were initially found 
to solve only acyclic digraphs, while the FEAT algorithm 
(FEAT3.3) and the AMES algorithm were designed to 
handle both cyclic and acyclic graphs. Cyclical digraphs 
are commonly found in models of actual systems because 
of feedback loops hydraulic and electrical systems, and 
other standard system designs. These loops could be 
manually or automatically found and broken to provide a 
quicker, but less satisfactory, answer because of the 
artificial nodes placed in the models to break the loops. 
Code to solve cyclic digraphs is currently being 
developed and tested in the ZR algorithm. To accurately 
compare each of the five algorithms, it was necessary to 
work with a set of acyclic graphs. A depth first search 
was used to determine those graphs that were acyclic. 

A set of the smaller digraphs was used to verify and 
validate each of the algorithms by hand. Solutions for 
larger digraphs from each of the algorithms were 
compared by sorting the final solution and performing a 
“diff” Unix command. Each algorithm was run on very 
small test models, which contained models known 
potentially to cause incorrect answers, and the results 
were manually validated as being correct. Once we were 
certain that each of the algorithms computed the same 
solution, the analysis of each of the algorithms began. 

The get-time-of-day function was installed in each 
algorithm to obtain the wall clock time of each run. Two 
times were recorded: preprocessing, which indicates the 
time spent to convert the input file into adjacency 
information; and transitive closure, which indicates the 
time spent to compute the reachability of the digraph. 


Computer 


34 



In an attempt to estimate the order of complexity of 
each algorithm, the time versus node data were analyzed 
by linear regression techniques to determine the 
coefficients to the following equation: 

t = a*N b (1) 

where 

t is the time in sec 

a is a multiplicative constant 

N is the number of nodes 

and b is the power constant. 

The power constant, b, provides an estimate of the 
order of the complexity of the computational algorithm. 

Results 

The following table shows the actual wall clock time 
for each of the algorithms for each of the acyclic digraphs 
listed below. The times listed in table 3 below are in 
seconds. The ZP results are prefaced by “8” in the 
following tables and figures to indicate that the parallel 
algorithm was run on an eight processor hypercube. 

The b value shown in table 4 represents the estimate 
of the exponent of the function, b in equation 1, for the 
curves describing the time versus nodes data shown in 
table 3 and in figure 2. The 95% confidence intervals 
shown in table 4 indicate that the AMES algorithm has a 
significantly higher exponent than the Z family of 
algorithms. It also indicates that the ZP algorithm has a 
significantly lower exponent than the other algorithms. 

The FEAT3.3 data have too few data points to determine 
the exponent with sufficient precision to make any 
comparisons. The coefficient of determination, also 
called R2, is shown for each set of data. 


Conclusions 

The results indicate that the ZR and ZP algorithms 
appear to be faster than the other algorithms for acyclic 
graphs. However, many of the digraphs being developed 
for SSF contain cycles. Modification and testing of the 
ZR and ZP algorithms are currently under way. 

Two areas of study need to be pursued. First, the Z 
family algorithms require modification to allow correct 
processing of cyclic graphs. A follow-up set of timing 
runs needs to be completed to finally determine the 
appropriate algorithm(s) for incorporation into FEAT. 
Second, further analysis of the ZP algorithm with much 
larger model sizes is needed to verify the low b value 
observed during these tests. 
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Figure 1. Graph Illustrating Z1 Algorithm Computation. 
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Table 3. Actual Wall Clock Time for Algorithms 
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gure 2 graphically displays the data shown in table 3. 
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Figure 2. Graphical Display of Data in Table 2. 
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Table 4 shows the estimated complexity for each of the algorithms. 


Table 4. Estimated Complexity of Algorithms 
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Abstract 

Understanding risks and avoiding failure are daily 
concerns for the women and men of NASA. Although 
NASA’s mission propels us to push the limits of 
technology, and though the risks are considerable, the 
NASA community has, instilled within it, the 
determination to preserve the integrity of the systems 
upon which our mission and our employees’ lives and 
well-being depend. One of the ways this is being done is 
by expanding and improving the tools used to perform 
risk assessment. The failure environment analysis tool 
(FEAT) was developed to help engineers and analysts 
conduct risk assessment and failure analysis more 
thoroughly and reliably. The FEAT accomplishes this by 
providing answers to questions regarding what might 
have caused a particular failure, or, conversely, what 
effect the occurrence of a failure might have on an entire 
system. Additionally, FEAT can determine what 
common causes could have resulted in other 
combinations of failures. FEAT will even help determine 
the vulnerability of a system to failures, in light of 
reduced capability. Also, FEAT is useful in training 
personnel who must develop an understanding of 
particular systems. FEAT facilitates training on system 
behavior by providing an automated environment in 
which to conduct “what-if ’ evaluation. These types of 
analyses make FEAT a valuable tool for engineers and 
operations personnel in the design, analysis, and operation 
of NASA space systems. 

Introduction and Problem Statement 

FEAT was developed as part of an effort to find ways 
to identify and understand potential failures better that 
threaten the integrity of NASA systems. Past and current 
methods of failure assessment consist of developing often 
enormous amounts of documentation in the form of 
failure mode effect analysis (FMEA) worksheets. 
Engineers create these worksheets by exhaustively 
attempting to enumerate potential system failures and 
consequences. Hazards analysis is performed in a similar 
manner; experts are gathered together and are asked to 
brainstorm about the hazardous manifestations of various 
failures. System knowledge and experience are necessary 
for ensuring the comprehensiveness of this approach. 
There are, however, troubling drawbacks to this 
technique. First, the difficulty exists of anticipating every 
scenario. Analysis is also inherently constrained by the 
limits of actual experience. Further, such methods lack 


consistency and do not enforce a standard level of 
coverage. Although there is certainly much to be credited 
to knowledge acquired through experience, it is not 
sufficient to avoid unanticipated interactions that may 
lead unexpectedly to undesirable consequences. As many 
industries have learned, sometimes experience comes at 
too high a cost. Those at NASA have been looking for 
better ways to anticipate failure and for tools to assist in 
“designing out” potential problems. FEAT was 
developed to address this problem. 

Technical Approach 

FEAT is a software application that uses directed 
graphs, or digraphs, to analyze failure paths and failure 
event propagation. The behavior of the systems to be 
analyzed is represented as a digraph. Then, the digraph 
model of the system is used by FEAT to answer questions 
concerning the cause and effect of events that are captured 
in the model. The first step, therefore, in using FEAT is 
to create the digraph model of the system in which one is 
interested. Once FEAT has analyzed the digraph, it has 
the information it needs to perform cause-and-effect 
analysis. 

What are digraphs? Directed graphs are graphs that 
consist of a set of vertices and a set of edges, where there 
is an edge from one vertex a to another vertex b . The 
vertices are drawn as circles, and the edges are drawn as 
arrows. The direction of the arrows indicates a causal 
relationship between the vertices (fig. 1). The vertex 
from which the edge begins is called its source, and the 
vertex at which the edge terminates is called its target. 
Direct graph theory is an accepted and established area of 
mathematical study. We will, therefore, only introduce it 
in this paper to the extent necessary for an understanding 
of how it is used in FEAT. The interested reader may 
find further information by consulting the literature. 

The structure of the digraph can be represented by a 
matrix and, consequently, can be easily implemented in a 
computer. The conversion from digraph to matrix is 
straightforward and is illustrated below in figure 2. This 
matrix is called the adjacency matrix (ref. 1) and is the 
basis from which other information about the graph can 
be derived. The matrix of the graph is obtained by 
entering either zero or one, depending on whether or not 
an edge connects two vertices. The presence of an edge 
from a to b in figure 1 indicates an entry of one (1) into 
the corresponding matrix entry. However, since there is 
no edge from a to c, a zero (0) would be entered in the 
corresponding matrix entry. 
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Additional information can be added to the digraph 
by applying logical operators to express conditional 
statements. FEAT uses AND and OR operators to 
accomplish its analysis. The AND operator is represented 
on the graph as a vertical bar with a horizontally placed 
arrow at its center. An OR operator is simply two or 
more edges whose target is the same vertex. These 
operators (fig. 3) and their use in FEAT (figs. 4 and 5) are 
described below. 

The “AND” gate is shown in figure 5. The AND gate 
is used when both Event A and Event B must occur for 
Event C to occur. Conversely, if only Event A occurs or 
if only Event B occurs, Event C does not occur. 

Analytical Capabilities The reachability of an event 
refers to whether there is a path by which other events in 
the digraph can be reached. A given event is said to reach 
another, if the first event can cause the second through 
some path of the graph. Using the adjacency information 
derived from the digraph, reachability can be computed 
for every event and pair of events in the digraph. 

Analysis can be conducted upstream or downstream from 
an event node. (References 2, 3, and 4 provide a much 
more detailed discussion of digraphs and reachability.) 

Reachability information allows FEAT to answer the 
following questions about a modeled system: 

• What happens to the system if “Event A (and Event B 
and Event C and ...)” occurs? 

• What are the possible causes of “Event A”? 

• What common cause could account for the 
simultaneous indication of numerous events? 

• What is the susceptibility of the system to new events, 
given that one or more events have already occurred or 
the system has been reconfigured because of, for 
example, maintenance? 

Digraph Example The following example 
demonstrates how a digraph might be implemented for a 
light and switch. The digraph provides a methodical way 
in which to express the topology and behavior of a 
system. It is worth noting that the digraph itself may have 
various constructions for the same information contained 
in it, depending on who created it. Different modelers 
may lay out the digraph differently. However, for a 
properly constructed digraph, the same information will 
be captured. In the following example (figs. 6 and 7), 
power source A provides current to switch A, which 
connects to the bulb. Similarly, power source B can 
energize the bulb. 

• If “Power Source A Fails” or “Switch A Fails Open,” 
then “Switch A Output Fails.” This is an example of 
OR logic and is shown in the digraph by the arrows 
leading into “Switch A Output Fails.” 

• If output from both switches A and B fails, they will 
cause the “Power at Light to Fail.” This logic appears 
as an AND gate on the digraph (the vertical line). In 
this case, the AND gate reflects redundancy designed 
into a system. 


Why digraphs? 

Directed graphs are useful because they visually 
depict the logical topology and dependency relationships 
of physical and conceptual systems and processes. 

Because they capture causal effects between events, they 
can be used to describe system behavior. Directed graphs 
are also easily converted into a matrix and, because of 
this, can be readily analyzed in a computer. Creating and 
laying out the digraph of a system also formalizes the 
method of evaluation during the analytical process and 
provides a standard representation convention. Finally, 
digraph analysis is mathematically sound, since methods 
for determining connectivity paths of the digraph vertices 
can be mathematically proved. 

Method: Directed Graphs and FEAT 

Digraph construction is facilitated by use of an editor 
specifically designed for the task. Such an editor is 
included in the FEAT package, which consists of two 
programs: Digraph Editor and FEAT. 

Digraph Editor 

The Digraph Editor facilitates construction of the 
digraph model by allowing the user to create event nodes, 
edges, and the logic operators, and to connect and arrange 
them into a digraph. Event nodes and edges are laid out 
and connected using the logic operators. The pieces that 
make up a digraph are supplied in a digraph toolbox from 
which items may be selected. These items are placed on 
the screen and arranged to produce the system digraph. 

Other information is needed to complete the digraph 
and to make it usable by FEAT. Event nodes have an 
associated text block, which includes information that will 
identify the event node to FEAT, describe the event for 
the user, and relate the event to a drawing that contains 
the component to which the event pertains. This 
information is extracted from tables that the user creates. 
Digraph Editor uses the tables to generate automatically a 
mnemonic reference that FEAT will use to identify the 
event. 

Digraph Editor also provides a number of tools for 
validating and verifying the model as it is being 
developed. Digraph Editor will check tables for duplicate 
entries, check nodes for incorrect form, and determine 
whether a selected node has a duplicate in the digraph. 
Digraph Editor also contains an algorithm that allows the 
user to analyze small or incomplete digraphs while still in 
the editor. Once the digraph is completed and the paths in 
it are analyzed, FEAT can return answers to questions 
regarding the behavior of the modeled system. 

Currently, digraph models are created manually by 
selecting and arranging digraph components; the modeler 
must interpret drawings and other sources of information 
to generate the digraphs. This is a laborious task. 
Consequently, efforts are under way to develop methods 
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to translate schematics and drawings automatically into 
corresponding digraph models. 

Digraph Editor is currently only available for the 
Macintosh II class of computer. 

FEAT 

FEAT is the portion of the package that analyzes 
single or multiple digraphs and graphically displays 
causes and effects of events. Propagation results are 
shown both on the digraphs and on an another associated 
graphical representation, such as a schematic or block 
diagram. FEAT uses a multi-step algorithm, described in 
Reference 2, to compute reachability for each event and 
pair of events in the digraphs. Events are identified to 
FEAT through the mnemonic that is generated by Digraph 
Editor. Queries about the behavior of the system are 
made by selecting events and telling FEAT to return all of 
the causes of that event (targeting), or by telling FEAT to 
return all of the effects of that event (sourcing). FEAT 
displays all of the single events, and all pairs of events, 
that may cause a selected event. Multiple events may also 
be selected and analyzed. FEAT allows some events to 
be temporarily removed from the analysis so answers can 
be obtained about a reconfigured system. 

FEAT also contains a feature that allows users to 
attach to a schematic, formatted data base information 
and graphics. In this way, component descriptions, parts 
lists, drawings, etc., may be displayed in conjunction with 
a schematic. 

One of the major advantages of FEAT, as discussed 
in Reference 2, is that it allows the analysis of very large 
systems. Large systems can be digraphed by creating and 
connecting a series of smaller digraphs. FEAT 
understands when propagation occurs across the digraphs. 

Planned enhancements to FEAT include the 
following: increasing the speed with which reachability is 
computed by improving the FEAT computational 
algorithm; providing a method for computing and 
displaying probabilities of events occurring; and 
computing and displaying the time it takes for an event to 
propagate through the graph. 

FEAT is currently available for the Macintosh II class 
computer and for UNIX/X-Windows/OSF-Motif systems. 
No programming skill is required to use FEAT. A course, 
however, in digraph modeling is quite helpful in learning 
how to construct system models. 

Results: Digraphs at NASA 

Why NASA chose digraphs? 

NASA’s interest in digraphs began as part of the 
Shuttle Integrated Risk Assessment Project (SIRA). 

SIRA was initiated in the wake of the Challenger accident 
in an effort to find better ways of assessing risk and 
preventing failure. Digraphs support such analysis by 
providing end-to-end cause-and-effect analysis of 


modeled systems. Digraphs also provide a standard and 
methodical approach for conducting safety analysis and 
risk assessment. Digraphs capture information in an 
easily retrievable format and facilitate the transfer of 
design information. FEAT takes advantage of these 
characteristics in a way that aids engineers and analysts 
with design, assists safety engineers with risk assessment, 
and promotes understanding of system behavior, thereby 
making FEAT a good tool for training inexperienced 
persons. 

What has been done at NASA? 

The first system to which digraph analysis was 
applied was the Space Shuttle Main Engine System. 

Since then, acceptance of digraphs and the use of FEAT 
have extended in several directions. Most recently, FEAT 
has been formally released to the Space Station Freedom 
Program (SSFP) Technical Management Information 
System (TMIS), as Digraph Data System (DDS) release 
1.0. DDS will, through TMIS, be available to Space 
Station Freedom (SSF) Engineering and Integration, SSF 
Combined Control Center, and the various work packages 
and their contractors. A Macintosh Powerbook version of 
FEAT will be deployed as a development test objective 
(DTO) on the STS-52 flight scheduled for October 1992. 
Reliability and maintainability personnel at JSC are using 
FEAT to construct a model of the simplified aid for 
extravehicular activity rescue. FEAT is also being used to 
model the redesigned servo power amplifier for the 
remote manipulator system. 

Proponents have used FEAT for a variety of 
analytical tasks, such as fault tolerance analysis and 
redundancy management (FT/RM), fault detection, 
isolation, and recovery (FDIR), and “What-If” analysis. 
Within the SSFP, FEAT is being used in the performance 
of integrated risk assessment for the Station, which 
includes FMEA, hazards analysis, and FT/RM. FEAT 
has also been established as a baselined tool in the 
Mission Operations Combined Control Center, where 
flight controllers will use FEAT models to assist with 
real-time monitoring tasks. The FEAT role is expanding 
in both Space Station and in Space Shuttle. 

Space Station The Space Station Engineering 
Integration Contractor (SSEIC) is using FEAT to perform 
integrated risk assessment. This task consists of 
performing the analysis to assure that the Station design is 
safe, reliable, and has an acceptable level of risk (ref. 5). 
The Space Station design consists of modules designed 
and built by the United States and of modules that will be 
designed and built by NASA’s international partners. The 
work to be performed by NASA is divided into four work 
packages distributed among different centers. 

Additionally, a variety of contractors are working in 
support of the work packages. Consequently, system 
integration is a paramount concern of the program. 

SSEIC is tasked with ensuring the integration of these 
various factions and is using digraph-based FEAT to work 
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the integration problem. Specifically, FEAT supports the 
following areas of the integrated risk assessment process: 

• Reliability Analysis 

• Safety Analysis 

• Integrated Risk Analysis 

• Integrated Risk Assessment 

The models being developed for the Station 
integrated risk assessment will eventually be provided to 
Mission Operations personnel for use in FD1R of the on- 
orbit Station. 

Space Shuttle FEAT is scheduled to fly on STS-52 
as a DTO. A FEAT model of the S-band communications 
system has been installed on an Apple" Powerbook," 
which will be flown aboard the Shuttle. Astronauts will 
use the model to perform onboard fault isolation for the 
S-band communication system. They will be able to 
configure the model to match the actual S-band system 
configuration and then will use FEAT to identify possible 
causes of failures of the S-band system. 

Conclusions: Future Applications of 
Digraphs 

Digraphs are gaining acceptance, within the NASA 
community, as a viable method for conducting many 
kinds of analyses. SSFP and Operations has mandated the 
use of digraph analysis for the Space Station Level II 
Integration effort and many others are beginning to take 
up the banner. Some of the potential areas of application 
include the following: 

Fault Isolatlon/Testablllty 

FEAT’s ability to model and analyze system failures 
make it a natural candidate for fault isolation efforts. If a 
failure event occurs, FEAT can display all of the possible 
single and paired causes for that event. However, in a 
large system, potential causes can be enormous in 
number. A method of pruning the list of possible causes 
is then necessary. Sensor information associated with the 
system can be used to remove candidate causes that occur 
downstream of a known nominal condition. Incorporation 
of sensor data into the analysis can help reduce the 
number of candidate failures to a manageable sum. Then, 
using traditional techniques, further isolation can be 
accomplished. Figure 8 shows an example of such a case. 

Sensor data may also be combined with FEAT to 
identify the potential for cascading alarms. For instance, 
if a fault occurs downstream from a sensor, the sensors 
upstream will eventually alarm as a result of the fault. 
FEAT can show the effects of a fault on the downstream 
sensors. 

This solution is being implemented by NASA in an 
extension of FEAT, called extended real-time FEAT 
(ERF). ERF automatically prunes the list of possible 
faults according to sensor information. ERF is being 
developed as a part of the FDIR system for the On-orbit 
Control Center Complex. Mission controllers will use 


ERF to resolve off-nominal system behavior by reducing 
the potential number of failure causes. 

FEAT developers are pursuing the possibility of 
incorporating, or interfacing with, a testability analysis 
tool that will help to evaluate sensor coverage in systems 
and make recommendations regarding appropriate sensor 
locations. ERF is dependent upon adequate sensor 
information and proper placement of the sensors. 

Properly placed sensors provide information to locate 
faults quickly and accurately. The combination of FEAT, 
ERF, and testability tools will make a very powerful fault- 
isolation system. 

Temporal Analysis 

Not every event immediately affects the next 
downstream event. There may be appreciable delays 
within an event and between events. For example, an 
inappropriately shut valve may not, for some time, cause 
the pressure in the system to rise to an unacceptable level. 
In such a situation, time delay is an important aspect of 
calculating the potential failure space. 

This issue will be addressed in FEAT when a 
modification is made to Digraph Editor to allow modelers 
to include time delays within events and delays between 
events. FEAT will then compute the maximum and 
minimum time delay between selected events. This 
capability will be supplied in a future version of FEAT. 

Software Modeling 

Physical systems are not the only candidates for 
digraph analysis. Software functions and data flow can be 
modeled as well. Particularly, the flow and effect of 
invalid/improper data can be modeled. This can provide 
insight to the designer in determining mission-critical 
software functions. Additionally, the effect of invalid 
data on other system functions (both software and 
hardware) may be shown. For instance, a software 
functional component that generates invalid data as an 
event may then provide those data to other software and 
hardware as an invalid data input event. FEAT can be 
used to model these behaviors, too. 

Design Evaluation and Redundancy Management 

Digraph models can be used to determine whether or 
not a system design provides sufficient redundancy. 
Maintenance and configuration effects on the system can 
be evaluated by selectively removing (setting) 
components from the system. The reconfigured system 
can then be evaluated for induced single and paired 
events. This can be particularly useful in determining 
new vulnerabilities after a system has encountered 
failures and/or has portions of the system secured for 
maintenance. 

FEAT contributes to design evaluation by rapidly 
displaying all single events caused by the event of interest 
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as well as all pairs of events that will result in that event. 
Unexpected single-point, common-cause events are also 
quickly identified. As the design is modified to provide 
additional redundancy, the digraph model can be updated 
to reflect the changes, and the new set of single events 
and pairs of events can be evaluated. 

Logistics Analysis 

Logistics analysis addresses corrective and 
preventive maintenance tasks and determines the kinds 
and numbers of repair parts needed for a system. This 
type of analysis is associated with the reliability and 
availability (ref. 6) of systems. Reliability is defined as 
the measure of the mean time between failure and 
concerns the probability that a system will operate over a 
specified period of time. No provision is made for repair 
when calculating reliability. Availability varies from 
reliability, in that it is a measure of the mean time to 
repair or the probability that the system will operate over 
a period of time, considering that something can be done 
to restore functionality lost as a result of a failure. How 
system repairs can be supported, or supportability, is 
important to determining availability. If repairs can be 
made instantaneously, availability is increased. However, 
long delays between failure and repairs make the system 
proportionally less available. 

FEAT models can help to identify critical 
components and the effect of their failure upon the 
system. Digraph models of the system can, along with 
specific part reliability, help to determine priorities for 
inventory stocks and schedules for maintenance. Spare 
parts inventories are a major factor in determining 
supportability. For example, spares for parts that cause 
single-point, common-cause events should have higher 
priority for stocking than parts that contribute to pairs of 
events. 

Maintainability concerns the time it takes to remove 
and replace a component. Digraph models can identify 
components prone to low reliability and single common- 
cause failure. Designers can then either improve the 
reliability of the component or ensure that such items are 
accessible and easily replaced. 

Summary 

As NASA continues to search for better and 
innovative approaches to new and old problems, directed 
graph analysis has emerged as a viable addition to the 
methods applied to risk assessment. Directed graphs are a 
well-established area of mathematical study and analysis 
and provide an easily comprehensible visual 
representation of cause-and-effect relationships. 


Conversion of the digraph to an equivalent matrix is 
straightforward and allows analysis of digraphs to be 
mathematically calculated and verified. The nature of 
matrices also makes them ideally suited for computerized 
calculations, which in turn provide a vehicle for 
automating the task of risk assessment and failure 
analysis. 

FEAT uses directed graph theory to provide 
engineers and analysts with a powerful and flexible 
automated analytic helper. FEAT can provide end-to-end 
analysis of cause-and-effect events. Very large systems 
can be modeled in modules, then connected to form the 
entire system. This feature also allows digraphs to be 
arranged in mix and match fashion. FEAT can detect and 
return information about single-point failure vulnerability, 
failure-event pairs, common-cause events, and reduced 
capability analysis. FEAT shows the results of event 
propagation on system schematics and on the associated 
digraph. Digraph Editor provides a helpful way for the 
analyst to create digraphs. 
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Figure 1. A Digraph. 


a b c 
aO 1 0 
bO 0 1 
cO 0 0 

Figure 2. Conversion from Digraph to Matrix. 



Figure 3. The AND and OR Operators. 



Figure 4. The OR Operator as Used in FEAT. 


Computer 


44 



Event A 



Event A AND Event B cause Event C 


Figure 5. The AND Operator as Used in FEAT. 


Power 



Ground 

Figure 6. Light Bulb and Power Source Schematic. 


Switch A Fails Open 



Figure 7. Digraph of Light Bulb Schematic. 
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Sensor 1 



Event C Event D 

Sensor 1 


Event F may be caused be Events E or F directly or by Events A or B paired with 
Events C or D through the AND gate. 

Sensor I's state is unknown. 


Sensor 1 




Event C Brent D 


If Sensor 1 reports nominal conditions, this implies that neither Event A or Event B occurred. 
Since neither Event A or B occurred, then the AND gate condition cannot be met, and 
the only way Event F can occur is if Events E or F occur. The number of events necessary 
to be checked to evaluate the cause of Event F has been reduced from 6 to 2. 


Figure 8. FEAT Failure Analysis. 
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Application of Automation and Intelligent Software to Analysis of 
Engineering Space Shuttle Systems 

Ginger L. Pack 
Johnson Space Center/ER 


Abstract 

The role of mission evaluation room (MER) 
engineers is to provide engineering support for Space 
Shuttle systems. These engineers are concerned with 
ensuring that the systems for which they are responsible 
function reliably and as intended. The MER is a central 
facility from which engineers may work to fulfill this 
obligation. Engineers participate in real-time monitoring 
of Shuttle telemetry data and provide a variety of analyses 
associated with the operation of the Shuttle. 

Currently, the tasks involved with filling this role 
require excessive expenditure of human resources, which 
translates into unnecessarily high costs for Shuttle 
mission ground support. Prudent and judicious 
application of computer technology can reduce the cost of 
gathering and analyzing the data needed by engineers to 
fulfill Engineering’s MER responsibilities . 

The goal of the MER Intelligent Diagnostic and 
Analysis System (MIDAS) task is to streamline the 
engineering activity by applying advanced automation to 
eliminate some of the tasks humans are required to do, 
tasks which are better accomplished by computers, 
thereby reducing the computational burden placed upon 
humans and allowing engineers to quickly and accurately 
determine the health and status of their systems. 

This can be done by off-loading to computers and 
software the tasks of data gathering, filtering, and 
analysis. Incorporation of these tasks into software 
provides the engineers with information that is in a more 
concise and usable form needed to support decision 
making and engineering evaluation. Engineers are then 
able to concentrate on more difficult problems as they 
arise. 

Introduction 

The technology used to support MER engineering 
analysis activity has changed little since the days of 
NASA’s Apollo Program, which placed men on the 
Moon. Yet the reusable Space Shuttle is decidedly more 
complicated than the craft flown during the Apollo days. 
Engineers now must worry about long-term trends and 
effects of system behavior and performance. Data 
concerning past flights may be directly relevant to current 
operations. Also, flights are now commonly as long as 
8 to 10 days duration and occur at more frequent 
intervals. This places a great deal more burden on 
humans to process and analyze system information. 


These factors contribute to the complexity of analysis 
tasks and result in ever increasing amounts of data that 
engineers must collect and interpret. 

Advances in computer technology have provided the 
means to relieve humans of the burdensome aspects of 
some analysis. JSC’s Automation and Robotics Division 
is working to transfer advances in technology to the 
operational environment. Specifically, the MIDAS 
project provides MER engineers with software to assist 
them with monitoring, filtering, and analyzing Shuttle 
telemetry data during and after Shuttle missions. 

Problem Statement/Description 

Historically, engineers have had to rely strictly upon 
numerical values, displayed as ASCII text, to understand 
the state and operating condition of their system. 
Information in this form is crammed onto displays that 
engineers must monitor and interpret (fig. 1). Several of 
these displays exist for each subsystem. Engineers 
visually monitor these displays during missions to obtain 
an understanding of the behavior of their systems. Only 
one display at a time may be shown. This arrangement 
precludes the engineers noticing changes in information 
that is not contained on the display being viewed. The 
selection of screens available for viewing is controlled by 
Mission Operations personnel. During missions, 
engineers must often “chase around” the displays that 
contain the information in which they are interested. This 
further complicates the duties that engineers must perform 
to maintain the health of the systems for which they are 
responsible. 

There are several aspects to the work that engineers 
must do to monitor and analyze the behavior of Shuttle 
systems. Specific methods and approaches used depend 
upon the nature of the system. Some systems are 
analyzed by looking for the occurrence of known, 
expected behaviors and events. Others are better 
analyzed by looking for behaviors and events that do not 
fit known patterns. Still others may be understood in 
terms of past system behavior by comparing current 
behavior with historical information. 

Whatever view is taken of the system, the most basic- 
level task associated with accomplishing this work is that 
of monitoring the data as they are downlinked from the 
Orbiter. The data values found in the downlink consist of 
discrete valued parameters, which can be considered as 
on/off, or of set//un-set bits, and of analog parameters 
whose values are continuously increasing or decreasing. 


47 


Computer 


The configuration and/or behavior of these data values are 
used by engineers to infer the health and performance of 
Orbiter systems. 

The next level of tasks consists of identifying and 
collecting relevant data needed to support analysis and 
evaluation. Training and experience educate engineers to 
convert numerical information mentally into models of 
system behavior and performance. This in turn allows 
them to identify data that appear to be inconsistent with 
the expected model and its states. When appropriate sets 
of data have been defined and collected, various levels of 
detailed analysis can be performed. 

There are major drawbacks to using humans, as is 
now done, to perform all of these tasks. People must stare 
at screens full of data, and assimilate this information into 
a cohesive mental model of the system. Also, it is 
incumbent upon the engineer to notice that data have 
changed and to recognize the significance of a change. 
Even after the engineer has noticed something of interest 
and written it down on paper, it remains for the engineer 
to determine where, in the vast collection of mission data, 
relevant information is located. Often only a general idea 
of which data are needed is known by the engineer. A 
request for the actual data values is then submitted. If the 
range is off, another request must be generated and 
submitted for processing. Engineers may be required to 
submit several requests for data before actually obtaining 
the information that is relevant to their analysis. Often, 
engineers order up large numbers of plots, then pore over 
them to ascertain system behavior. 

Consequently, a great deal of effort goes into finding 
the data to be plotted, creating the plots, and refining the 
set of plots to reflect pertinent information prior to any 
analysis of the results. For some systems, plots of 
associated data are generated over a sequence of intervals, 
and the collection is reviewed in an effort to detect 
significant changes in the system. Working from the plots, 
engineers sift through data in an attempt to locate 
inconsistencies, confirm events, and gather supporting 
information for trend analysis. The engineer must be able 
to recognize and note any inconsistencies in the plotted 
data. Additional plots may be requested to confirm or 
dispel anomalies or “funnies” detected in the data and to 
support diagnosis of failed conditions. 

This mode of operation is plagued with inherent 
inefficiency. Humans are a poor choice for performing 
tedious and boring tasks such as continuous eyes-on 
monitoring. Distraction, boredom, and errors in 
translation from screen to paper are some of the pitfalls of 
this approach. Much time is also wasted in looking for 
and obtaining data for analysis. Further, system 
knowledge often remains locked up in the years of 
experience it takes to become proficient in these methods. 
Loss of such an employee, due to attrition and retirement, 
equals loss of the knowledge. 

Because engineers have few tools to assist them in 
gathering, filtering, and refining these large amounts of 
data, a significant amount of their efforts is dedicated to 


this process. This in turn translates into unnecessarily 
high costs for supporting Shuttle and, eventually, Station 
operations. Automation and intelligent software can be 
used to off-load the routine and tedious tasks, which 
comprise a large part of the MER engineer’s efforts, and 
to filter and refine data sets to contain pertinent 
information. Engineers will spend less time accumulating 
and sifting through data and more time performing 
analysis. Discussions with Orbiter subsystem managers 
reveal a real need for assistance in this area as flight rates 
increase, and as the prospects for increased amounts of 
continuously supplied data from Space Station Freedom 
systems become reality. 

Approach/Method 

The MIDAS project addresses these issues by 
providing software that selectively monitors data, filters 
data, and interprets and graphically displays results. 

Areas that have been identified as candidates for 
automation within the scope of this project include the 
following: 

• status monitoring and “smart” logging of system data to 
verify configuration and provide notification of 
incorrect or unexpected states 

• event detection and explanation to identify events that 
cannot be explained by known states and conditions 

• trend monitoring and recognition to assist in detecting 
wear and degradation of components 

• comparisons between current and historical data to 
enable detection of changes and inconsistencies in 
behavior 

• automated verification of in-flight checkout and 
associated fault diagnosis 

• calculation/prediction of consumption rates to enable 
management of resources 

• comparison of actual usage rates to predicted usage 
rates to detect leakage 

Automation requirements are developed through 
close interaction with Shuttle subsystem engineers. User 
feedback is solicited and incorporated into the 
architectural design, and the implementation of the 
design. Product reviews are also conducted with the user 
to ensure appropriateness and accuracy of results, and to 
train the user in operation of the application. Finally, 
products are iteratively revised after being used in the 
operational environment. This approach involves users 
continuously throughout the product development and 
implementation and gives them a stake in the final 
product. It also ensures user “buy in” to the technology, 
since they help to define the implementation of the 
technological solution. 

MIDAS applications are written in the “C” language 
using X-windows version 11, release 5 (X11R5), which is 
standard with most UNIX operating systems. Also used is 
the commercial off-the-shelf Motif widget set and an 
extensively modified public domain plot widget, from 
which some data displays are created. The applications 
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currently run on the SUN (OS 4.1.3 version of UNIX) 
Sparcl+ and Sparc2 machines, Masscomp workstations, 
and DEC stations. 

Results 

Several products have been generated under the 
MIDAS project. Applications have been developed for 
the tracking and communications system, the remote 
manipulator system (RMS), and the propulsion and power 
system. 

Fiscal year (FY) 1992 activity began by converting 
previously developed applications to XWindows. 

Tracking and communication was the first system for 
which applications were constructed. During FY 1992, 
an existing application, the S-band automated monitor and 
logging application, was cloned and applied to the 
payload communications systems and the text and 
graphics system (TAGS). The S-band, payload, and 
TAGS logging functions automatically monitor and log 
discrete parameters for each of these systems. Results are 
displayed on a screen and are also written to a file. 
Information included in the log consists of the previous 
value of the changed parameter, the new value of the 
parameter, the Greenwich mean time (GMT), and the 
mission elapsed time (MET). Users may also attach a 
comment to any entry in the log, either by entering the 
comment through an edit function or by selecting a 
previously defined “canned” comment (fig. 2). 

Another S-band Comm System application was 
constructed to monitor the S-band analog parameters. 

This application continuously monitors and plots the 
value of the S-band analog parameters. The plots are 
organized into pages, with three plots to a page and up to 
four curves per page. Curves may reflect a specific 
parameter value over time or may be calculated using 
some combination of parameters or other logic. Pages 
may be viewed singly or two at a time. Pages may be 
combined in any order. 

The forward link status application automatically 
collects statistical data on the availability of the S-band 
antenna system. Logic in the software monitors, 
identifies, and records the occurrence and duration of 
drops in the forward communications link. Statistics on 
the usage and performance of the antenna are collected 
and displayed. Similar information is displayed on an 
application that tracks the position of the Shuttle and 
orbital trace over a world map (fig. 3). 

The Tracking and Communications applications have 
been used by engineers during each mission since the 
launch of STS-32. 

In April 1992, an application for the RMS was 
completed and deployed. The direct drive test (DDT) 


monitor (fig. 4) was constructed to monitor the DDT of 
the RMS joint motors. The six joints of the Shuttle 
robotic arm are moved by six motors, which are tested 
before the arm is deployed. The motors are tested by 
driving each of them in the forward (positive) and reverse 
(negative) positions. The DDT monitor automatically 
detects the initiation of the direct drive test and plots the 
results on a screen as the test occurs. The plotted data can 
be overlaid upon a historical template of DDT data for 
comparison of current behavior to past behavior. This 
software is used whenever a flight includes use of the 
Shuttle robotic arm. 

During 1992, MIDAS was also extended to include 
the fuel cells and power reactant storage and distribution 
(PRSD) systems. Applications were defined that assist 
engineers in determining leak rates and consumption rates 
for the Orbiter fuel tanks. This analysis will become 
increasingly important when the long-duration Orbiter is 
in use. 

Conclusions 

Past MIDAS efforts have provided the groundwork 
for more sophisticated automated analysis. Plans for FY 
1993 include an Intelligent Ku-band self-test monitor. 
This application will detect the occurrence of the Ku-band 
self-test, monitor its progress, and analyze the results of 
the test. Deployment of the first version of this software 
is scheduled for the fall of 1993. 

Other efforts will be dedicated to completion of the 
fuel cells and PRSD applications, and to extending the 
MIDAS work to another area, the crew and thermal 
systems. 

References 

‘MIDAS Applications Description Sheet. 

2 MIDAS FY 93 Project Schedule. 

3 MIDAS Software Requirements Document. 

Acknowledg merits 

The MIDAS project is sponsored by the Automation 
and Robotics Division, Intelligent Systems Branch, with 
funding from the Orbiter Projects Office at JSC. The 
NASA project manager for this task is Ginger L. Pack/ 
ER2. Programming support is performed by the NASA 
engineering support contractor, Lockheed Engineering 
and Sciences Corporation (LESC). The programmers for 
this task are Jane Falgout, Joe Barcio, Leroy Gay, and 
Charles Smith, all of LESC. 


49 


j Computer 



DN 2 2 


F/V 49/ 105 

OOMT 131 :21s 16:39 OMET 
RGMT 131:21:16:39 U/D ROTE 


RMS STATUS 

2:21:36:H1 SITE TOR 01 161 


RR3582M CH029 

Sh 24 BF 13 


RMS PMR 

PR I 

ENTER 6 



RMS SEL 

PORT 

MODE 


MCIU I/O 

ON 

ORB UNL 

0 

0 

BYPOSS 

0 

SINGLE 

0 

0 



END EFF 

0 

8 

SOFT STP 

ENO 

ORB LD 

SEL 

IND 

PUTO BRK 

ENO 

PL 

8 

0 

ENCDR CK 

ENO 

OPR CMD 

8 

0 



PUTO 1 

8 

0 

EE ID 

1 

OUTO 2 

0 

8 

PL ID 

1 

PUTO 3 

6 

0 



OUTO 4 

8 

0 

PL INI ID 1 

TEST 

8 

0 

OCOS CK 

GOOD 

DIRECT 

0 




SIN/DIR 



REODY 

0 




PROCEED 

0 

POROMETER 

PNGL 

IN PROG 

0 




STOP 

G 

BROKES 

0 

0 



S/M STOP 


8 

STORT PT 

1 

SOFING 

0 

0 

LOST PT 

0 



0 



ROTE VERN 

IND 

#1 #2 *3 #4 

HOLD 

OUT 

0 

1 2 

3 4 

SCOLE 


X10 


0 INRL 
OTT DB 
RT LIh 
DSC RT 
CNTL OCCL 
JET OPT P 


VERM 
1 . 808 
8. 828 
8. 20 
0. 02300 
NOH (TOIL) 


OLT 

OLT 

DLY 

ON 



X 

Y 

2 

P 

Y 

R 

POR 

979 

-77 

-425 

244. 3 

358. 8 

356. 9 

POR RT 

-0. 80 

0. 00 

-0. 00 

-8. 04 

-0. 82 

e. 01 

HC CNT 

0 

0 

0 

0 

0 

0 NUL 

OCOS 

883 

- 1 S3 

-658 

188 

0 

0 


SY 

SP 

EP 

MP 

MY 

MR RNG 3 

ONG OCT 

-8. S 

79.9 - 

127. 4 

-48. 2 

-72.9 - 

139. 6 

JT SM 

0 

0 

0 

0 

0 

MR 0 0 

MOT CMD 

-0. 0 

-0. 1 

-0. 0 

-0. 0 

0. 1 

-0. 0 

TOCH PCT 

-0. 4 

0. 0 

-0. 3 

0. 0 

-0. 1 

0. 0 


MCIU 


NMI 
MODC 
MCPC 
ICF 

PBE/MCIU 

gpc conn 

EE DERIGID 

RELEASE 

PORT TEMP 


CRT 


JET OPT 1 
MAX JET 2 
TIME 0.00 
TIME 0.08 
X Y 2 
TRONS P P P 


MCIU/DC 
THERM CKT 
EE FLOG 
EE CMDS 
EEEU BITE 
MCIU HC 
EXT FS 
TEST BRK 
C/M 
NMI 
LOSS 
FS 


EE MODE: 

COP 

RIG 

DERIG 

REL 


CUR PTTN: SH 2 MR 2 


RIGID 

BP 

DERIG 

DRY 


CLOSE 

BP 

OPEN 

DRY 


COPTURE 

BP 

EXTEND 

DRY 


SY SP EP MP MY MR 


QBE 

SPO 

SPO 


TOCH 
+ 28 V 
COMMUT 
MDO 
JPC 

CRT POS< EMC ) 
CKT ERR TOCH 
ENVEL 

S TOLLED 
SLUGGISH 


LOM-2 8 Y 1 
RONGE 

NOM (TOIL) ROT 

ATTITUDE 

CURR ERR TOT 

D D D 
INERTL 
ROTE 

1 

2 


PDRS 

PDRS 

SLIP 

SLIP 

FAULT 

EP 

EP 

SUMM MSG — 
4 
4 

131:21: 14:38 
131:21: 13:53 

272 R 

325. 89 

-1. 87 

0. 802 

3 

S96 

PDRS 

RCH 

EP 

4 

131: 19:38:37 

RNDE RTE P 

326. 11 

-21. 00 

-0. 003 

4 

S96 

PDRS 

RCH 

SP 

4 

131: 19:38:37 

-0.4O Y 

60. 82 

-0. 05 

0. 000 

5 


PDRS 

SING 

EP 

4 

131: 19:38:37 


Figure 1. RMS Status. 


Computer 


50 





MISSION 37 VEHICLE 104 


- — - 

n#s i* vi fw COMMUI 

Mm i x 

^ICATIONS AND TR/ 

Sir J \ J 5 B— i _ 

DIKING 

s \W WOOF 
SIC STR 
PN ERR 
P* IOCK 
FIFO 

irscr rvca 

R TN AGC 

ANT MOOT 
SEtECT 

PA STNOBY 
POWER 

Rfl pwr 

RATE 
SOURCE 
FS/BER 
FM HF HI 
SOURCE 
KMT PWR 

Ku BANO ACC 
216 FR SYNC 
DATA 
AN T 

ROll/PIT / 

TEMP 

MAD 

CH 1 2 J 

|| *band [ PAGE DOWN | PACE UP J SEARCH 

TOP | BOTTOM J LINE UP J FINE DOWN [ 

OTHER J QUIT 


UtF EF AM SW 


SM 






*r 
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Figure 3. Display of a Tracking and Communications Application Which Tracks the Position of the Shuttle and Orbital 

Trace Over a World Map. 
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Abstract 

Expert systems for monitoring and diagnosing real- 
time space operations must address the challenges of 
incorrect, noisy, and missing real-time data. 

Conventional approaches to solving such problems are 
not adequate to achieve the tolerance for bad data 
exhibited by human experts monitoring dynamic systems. 
We propose a set of methods to handle data problems, 
including rule disabling, use of context, and expectations 
to make assessments that tolerate some bad data, and 
graceful recovery through system correction when reliable 
data return. These methods have been used in a prototype 
called DESSY, or Decision Support System, a rule-based 
system that monitors the operational state and status of 
the manipulator positioning mechanism and manipulator 
retention latches (MPM/MRL) systems of the Space 
Shuttle payload deployment and retrieval system (PDRS). 
This robust monitoring system is capable of lengthy 
periods of uninterrupted use in real-time operations and 
has been successfully demonstrated in the Mission 
Control Center during Shuttle missions. 

Introduction 

Intelligent systems for computer-assisted support 
during aerospace operations usually provide real-time 
data monitoring and failure diagnosis. A major challenge 
for these systems is robustness in handling unreliable 
data. The principal real-time telemetry data problems 
encountered in space operations include (1) missing data, 
(2) erratic or noisy data, and (3) data lags and 
irregularities during state transitions, commanding, and 
other operational events. We describe a combination of 
methods to handle these types of data problems, including 
rule disabling, use of context and expectations to make 
assessments that tolerate some bad data, and graceful 
recovery through system correction when reliable data 
returns. Although all telemetry data monitored by this 
application are binary, these problems could occur with 
any data format. 

Conventional approaches, such as data filtering or 
data validation, may not be sufficient to eliminate all bad 
data, and the use of unfiltered data gives the flight 
controller a better understanding of the telemetry. 
Statistical approaches 2,6 ’* use sampling and statistical 
testing or probability estimates; however, these 
approaches may require sample sizes or sensor 
redundancy that is not available. Another approach, 


sensor failure diagnosis, 7 requires sensor redundancy or 
testing to identify the failures and to shift the focus from 
process monitoring to sensor diagnosis. An approach we 
use is to handle some bad data while relying on diagnostic 
expectations and the preponderance of the data. 1 Other 
similar approaches provide graceful degradation in the 
face of bad data, 4 permitting reasonable interim 
assessments while eliminating most false conclusions. 
However, since bad data will inevitably enter the system, 
a recovery approach is needed. A system should be able 
to recover by incrementally reinterpreting data as the data 
are gathered. 3 Our recovery implementation, graceful 
recovery involves both the reevaluation of new data as the 
data enter the system and adjustments of expert system 
conclusions based on those data. 

Problem Statement/Description 

A real-time expert system must address three major 
types of data problems. They are (1) missing data, 

(2) erratic or noisy data, and (3) data lags and irregu- 
larities during operational events. Each has its own 
distinguishing characteristics and each can affect the 
monitoring system in a different way. Thus, to build a 
robust system, all data problems must be addressed both 
stand alone and together. 

Loss of Data 

The most common data problem is loss. Data loss 
usually takes the form of a complete loss of signal (LOS) 
and may be unexpected or expected; i.e., when the Shuttle 
enters the zone of exclusion (ZOE) where there is no 
telemetry downlink. Unexpected data loss may occur due 
to ground processing or computer hardware problems. 
Although LOS seems a simple phenomenon to account 
for, hardware implementation of telemetry processors can 
complicate the situation. Depending upon how the 
telemetry processor handles LOS, the monitoring system 
may receive an inactive state for all data, no data, or a 
static frame of the last data. The first step in dealing with 
loss of data due to LOS is to find out the form of data that 
will be received during this time. To detect LOS in 
DESSY, we used a data quality measurement directly 
from the telemetry processor called OI-Quality. 

However, OI-Quality does not always reflect true data 
quality, and, inevitably, bad data periodically enters the 
system. 
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Erratic Data 

Erratic data are unstable and do not meet expected 
behavior for a given operational context. Such data are 
most likely seen immediately before or after LOS or at the 
time of state transitions. Erratic data are characterized by 
frequent flipping of bits (in the binary case) in a data set. 
Bit flipping occurs when a data value toggles between 
values of 0 and 1. This signature may also result from 
intermittent sensor failures, and that possibility should not 
be ruled out. For large sets of data, however, it is more 
likely that bit flipping is due to bad data rather than bad 
sensors. For DESSY, periods surrounding an LOS are a 
common time for erratic data to appear. As the Space 
Shuttle moves in or out of a satellite range, the telemetry 
link has a period of degradation, during which the 01- 
Quality has not yet dropped. The result is a significant 
amount of bad data entering DESSY. Because there has 
been no previous low quality indication, DESSY has no 
indication of the degraded data and is thus susceptible to 
errors. 

Data Lags and Irregularities During Operational 
Events 

The final type of data problem results from 
unexpected data activity when data are expected to 
change because of an operational event such as a state 
transition or command. Data that are expected to change 
may "flicker” or "lag” before reaching a new stable state. 
Given a set of data that is expected to change at transition 
time T, subsets may flicker or lag, causing the data 
transition to occur over some delta time t. Typically delta 
t is 1-3 seconds. Figure 1 depicts five examples of data 
transitions from low to high values, including a normal 
data transition and four anomalous cases. The delta time 
for this data set, 2 sec, is the time it took for every piece 
of data in the set to change to its new expected value. 

Data lags and irregularities during operational events may 
occur because of telemetry noise or may be owing to the 
physical properties of the hardware being monitored. 
Failure to include this behavior in the system monitoring 
rules will often lead to erroneous conclusions. 

Approach/Method 

Our approach to dealing with unreliable telemetry 
data attempts to achieve human-like tolerance to bad data. 
We tolerate data problems by monitoring data quality, 
using diagnostic expectations, and correcting wrong 
conclusions when good data returns. Table I lists each of 
the data problems with their applicable solutions. These 
methods include rule disabling to ignore data when data 
quality is low or uncertain, context-sensitive pattern 
recognition for minimizing incorrect conclusions based on 
bad data that has entered the system, and graceful 
recovery through system correction when reliable data 


returns. Each method works independently to prevent or 
correct erroneous expert system conclusions resulting 
from bad or missing data. It is their combination, 
however, that assures a robust program capable of lengthy 
periods of uninterrupted use in operations. 

Rule Disabling 

The most straightforward method of handling data of 
uncertain quality is not to respond to changes in those 
data. There may be times when data quality is so low that 
the data should not be used at all. The expert system 
should, therefore, be capable of ignoring data when the 
data are unreliable by a method such as disabling rule 
sets. Although this tactic seems simple, the quality 
indicator and its data are in the same timeframe, making 
immediate disablement impossible. Also, as the Shuttle 
enters or leaves the ZOE, the telemetry link deteriorates, 
and 01-Quality itself is unreliable at that time. However, 
although erroneous data may have already entered the 
system, it is still desirable to disable rules to minimize the 
number of faulty conclusions. 

To supplement automatic rule disabling, the DESSY 
user may also “turn off' the expert system portion of 
DESSY at any time, leaving DESSY to act as only a data 
monitor. Actually, this turning off merely grays out parts 
of the DESSY display that present expert system 
conclusions, allowing DESSY to continue to work in the 
background. Even if DESSY has made incorrect 
conclusions and the user has grayed out the expert system 
part of the DESSY screen, the built-in self-corrective 
rules should eventually lead to recovery. The intent is 
that even if DESSY has been turned off because of 
erroneous expert system conclusions, it will recover by 
itself, and the user will once again be able to use the 
expert system part of DESSY. Nonetheless, this feature 
gives the user the opportunity to override the expert 
system at the level of user interface. 3 

Context-Sensitive Pattern Recognition 

The second technique we have implemented to assure 
DESSY robustness deals with characteristics of the sets of 
data that DESSY uses to detect events and identify 
failures. Because of problems with data lags and 
irregularities, the expert system often has insufficient or 
even erroneous evidence from the data set, upon which it 
can determine the occurrence of an event or failure. In 
DESSY we require that all rules except recovery rules 
tolerate a single data failure in any set of data we 
consider. If the data set is insufficient, context and 
expected events are included as a supplement of 
additional information. This inclusion of context and 
expected events eliminates many problems associated 
with insufficient or incorrect data. This includes both 
false conclusions and failure of the system to make an 
expected conclusion. 
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Graceful Recovery Through System Correction 

Although some expert systems attempt graceful 
degradation in the face of trouble, DESSY has extended 
this concept to one of graceful recovery. If the system 
makes faulty conclusions because of bad data, a set of 
corrective rules acts to restore the expert system once 
good data return. This includes correction of individual 
data, state, and status. The system does not have to be 
restarted by the user, because the corrections 
automatically restore offending parts of the knowledge 
base. Corrective rules are similar to other system 
monitoring rules, except that they do not allow for any 
inconsistencies in the data sets they observe when making 
conclusions; i.e., every piece of data in the set must be 
exactly correct. Additionally, corrective rules are written 
only for the cases where the system can be determined 
with certainty to be in a particular configuration. These 
rules, therefore, can be thought of as the axioms of the 
expert system. They can be as simple as determining that 
a single piece of data is reliable again because it returned 
to a legitimate value after it had previously been deemed 
unreliable. A more sophisticated example is the 
reevaluation of system state when all data for a new state 
become active. 

We have found the correction features not only to be 
very useful, but to have good side effects. 

Complementing the correction rules, initialization rules 
allow DESSY to be started during any stable MPM/MRL 
configuration and to be initialized to the proper states and 
statuses. In addition, if DESSY is started during 
transition periods, once the transition is complete, DESSY 
can initialize itself. This has been an important and even 
necessary feature of our real-time expert system. 

Results 

DESSY is implemented in a commercial real-time 
expert system development environment. The system 
currently monitors approximately 80 pieces of MPM/ 
MRL telemetry, receiving its data once each second. 
DESSY has been demonstrated successfully in Mission 
Control during the STS-46 and STS-49 missions and has 
been used in Mission Control integrated training 
simulations. Benefits of our data handling methods, 
especially graceful recovery, have been demonstrated 
regularly in Space Shuttle missions, showing the 
robustness of the software. A scenario observed during 
STS-49 depicts a typical case. Because of ground 
hardware problems, a significant amount of data frames 
were being lost, so DESSY did not receive data for 
seconds at a time. Unfortunately, those were crucial 
seconds in which an MRL state transition was taking 
place. DESSY was unable to monitor the transition 
procedure, because it never received the data. When 
DESSY did receive a data frame again, although the 
procedure was over, it was able to evaluate the current 
data and reflect the new MRL state. A similar example 


occurred during MRL operations during STS-46. 

Seconds after an MRL release began, an LOS occurred, 
and the telemetry downlink was lost. This LOS lasted 
several minutes, and when data returned, the operation 
was complete. At this time, DESSY evaluated the new 
data and reconfigured itself to reflect the new MRL state. 
In both cases, it was unfortunate that we were not able to 
monitor the operations, but the fact that DESSY was able 
to keep up once data returned prevented a situation where 
the wrong state would be reflected, certainly causing a 
loss of user confidence. 

Conclusions 

The data handling techniques implemented in 
DESSY have repeatedly proved to be effective in 
maintaining robust expert system operation while 
tolerating bad data. Disabling rules when data are 
unreliable reflect the human process of ignoring bad data 
at this time. The pattern recognition approach allows 
tolerance in conclusions by considering context and 
expectations. Finally, if the expert system makes a 
mistake based on bad data, we provide a mechanism for 
graceful recovery. Although each of the techniques we 
use has merit by itself, it is their combination that most 
reflects the human monitoring process and allows us to 
build a system with a human-like level of tolerance to 
data problems. 

The future DESSY goal is to complete all modules of 
the PDRS, and currently the end effector system is being 
implemented. This will add a new level of complexity to 
DESSY, particularly in module integration. Also, a 
developer's guide for real-time automation software for 
Mission Control is to be a product of the DESSY project. 
We hope to document our own lessons learned to provide 
others in the space industry with development guidelines. 
The content will include the design and development 
process and issues concerning robustness and usability. 
We believe that the guidelines we are developing provide 
a good set of ground rules from which a robust and useful 
system can be built for real-time monitoring. 
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Figure 1. Examples of Data Lags and Irregularities. 
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Abstract 

Teleoperated robots require one or more humans to 
control actuators, mechanisms, and other robot equipment 
given feedback from onboard sensors. To accomplish this 
task, the human requires some form of control station. 
Desirable features of such a control station include 
operation by a single human, comfort, and natural human 
interfaces (visual, audio, motion, tactile, etc.). These 
interfaces should work to maximize performance of the 
human/robot system by streamlining the link between the 
human brain and the robot equipment. 

This paper describes development of a control station 
test-bed with the characteristics described above. Initially, 
this test-bed will be used to control two teleoperated robots. 
Features of the robots include anthropomorphic 
mechanisms, slaving to the test-bed, and delivery of sensory 
feedback to the test-bed. The test-bed will make use of 
technologies such as helmet-mounted displays, voice 
recognition, and exoskeleton masters. It will allow for 
integration and testing of emerging telepresence 
technologies along with techniques for coping with control 
link time delays. 

Systems developed from this test-bed could be applied 
to ground control of space-based robots. During man- 
tended operations, Space Station Freedom may benefit from 
ground control of intravehicular activity (IV A) or 
extravehicular activity (EVA) robots with science or 
maintenance tasks. Planetary exploration may also find 
advanced teleoperation systems to be very useful. 

Introduction 

Remotely controlled robots may be successfully 
applied in hazardous environments such as high-radiation 
zones, deep-sea locations, Earth orbit, and extraterrestrial 
sites. Three dominant control modes are teleoperation, 
supervised autonomy, and shared control. 1 Teleoperation is 
characterized by direct human-in-the-loop manual control 
and small time delays (< 1 sec). In supervised autonomy, 
commands are generated by the operator and sent to the 
robot control system for execution. Shared control makes 
use of both teleoperation inputs and an autonomous robot 
control system. In each of these modes, a human operator is 
involved who must interact with some form of computer- 
based control station. 

Figure 1 illustrates a spectrum of technologies that may 
be used in a remote robot-control station. At one end are 
conventional technologies such as hand controllers, 2-D 
video, keyboards, and computer monitors. The other end is 


labeled as telepresence technologies and includes force 
reflective exoskeletons, stereo (3-D) video, voice 
recognition, and synthetic speech. 

Telepresence can be defined as the sense of being 
physically present with an object(s) at a remote site. 3 
Telepresence technologies attempt to immerse a human 
operator in the remote environment with actuator control 
and sensory feedback devices that closely interface to the 
human central nervous system. Robots at the remote site 
are designed with anthropomorphic actuators and sensory 
devices, such as stereo camera pairs and tactile sensors. 

Telepresence technologies offer interfaces to the 
human sensory system, which are more direct than those of 
the conventional technologies defined. This frees the brain 
from many unnatural input/output conversion tasks, 
allowing more concentration on higher level control and 
process-oriented tasks. The result is a more intuitive way of 
controlling remote robots. 

Major challenges facing telepresence technologies 
include working with time delays, increasing video 
resolution and field of view, and providing adequate force/ 
torque and haptic feedback. 

Project Overview 

Objectives 

The primary project objective is to develop a 
teleoperator control station test-bed that makes use of 
telepresence technologies. This test-bed is referred to as the 
teleoperated robot interface platform (TRIP) and should 
provide teleoperation capabilities for two JSC development 
robots. One robot is the dexterous anthropomorphic robotic 
test-bed (DART). 4 DART is a dual-arm, dual-hand robot 
with a camera platform that provides stereo video. It will be 
able to operate under human control augmented by onboard 
intelligence for use in development of IVA and EVA 
robotic systems. The second, AERCAM, is a prototype 
mobile camera platform capable of teleoperation. Initially, 
this prototype will be flown on an air-bearing floor at JSC. 

In a more general sense, TRIP will be used as a test- 
bed for emerging telepresence technologies, such as head- 
mounted displays, exoskeletons, and programming systems. 
In addition, TRIP will allow testing of proposed solutions to 
the problems induced by control link time delays. Systems 
developed with the TRIP test-bed should support future 
operations on board the Space Station Freedom, including 
the possibility of ground control using shared control 
techniques. 
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Goals and Constraints 

TRIP development goals include flexibility, ease of 
use, and growth paths. A flexible system will support the 
test-bed objectives through maximum use of standard 
hardware and software interfaces, a modular approach to 
system design, and the use of software for most calibration 
tasks. The system should also allow for ease of 
development and use by minimizing and simplifying the 
software learning curves. Ease of use will support tight 
schedules and minimal manpower. A system designed with 
growth paths will foster an evolutionary development by 
protecting both hardware and software investments. Design 
for growth seeks to avoid obsolescence by choosing 
established software tools with supported growth paths and 
by avoiding hardware with closed or unsupported 
architectures. 

Development constraints consist of cost and system 
performance. Design must be sensitive to costs by 
maximizing system capability, given current year funding. 
Basic system-level results should not depend on large 
amounts of future funding. Basic performance 
requirements, such as data rates and connectivity, must also 
be satisfied. Optimization of performance variables at the 
expense of system flexibility will be avoided unless 
required. 

Facilities and Support 

TRIP is under development in the Dexterous Robotics 
Lab of the Automation and Robotics Division at JSC. The 
two target robots are also under development in division 
labs. To date, all primary design and development work has 
been conducted in-house by JSC civil service staff 
members. Only a limited amount of contractor support has 
been available or used. 

System Description 

Organization 

TRIP is the integration of assorted telepresence 
technologies as illustrated in figure 2. These include 
exoskeletons for the operator’s hand, wrist, and arm joints, a 
head-mounted display for viewing stereo video and 
graphics, speech synthesis and voice recognition systems, 
and a network interface for passing data to/from a remote 
robot. These systems should work in concert to provide 
intuitive control of a remote robot by one human operator. 
TRIP is organized into five subsystems, each consisting of 
hardware and associated software. 

Hardware Architecture 

The hardware architecture is shown in figure 3. 
Selections were driven primarily by the flexibility goal 
along with the availability and cost of both software and 
special-purpose boards (video, audio, etc.). Hardware cost 


and growth-path trends were also considered. 

The hardware architecture consists of exoskeletons, a 
head-mounted display, a chair platform with control pedals, 
i486 & i386 microprocessors in ISA and VME buses, and 
assorted I/O, audio, and video boards. A single family of 
processors was selected to minimize software learning 
curves and keep costs relatively low. The ISA bus offers 
reasonable performance and a myriad of low-cost, special- 
purpose I/O boards from which to choose. The VMEbus 
offers an industry standard with high bandwidth 
performance, extreme flexibility, and a large number of I/O 
and processor boards. Selections of boards for both buses 
were based on a balance of cost, flexibility, and 
performance. Software driver libraries were also considered 
in the board selections, as this represents a potentially labor- 
intensive set of development tasks. 

Exoskeletons are attached to a body harness and 
gloves, which the operator wears. An analog signal 
conditioning box provides power to the exoskeletons and 
filters the signals produced by potentiometers and hall- 
effect sensors. These signals are then read by an analog-to- 
digital (A/D) converter board in the VMEbus. An 
embedded i386 computer processes raw data from the A/D 
board and makes the results available on the VMEbus. 

The head-mounted display (HMD) consists of 
monitors, optics, a position sensor, headphones, and a 
microphone. The position sensor reports roll, pitch, and 
yaw to an embedded i386 computer via an RS-232 link 
from its own processor-based control box. Two i486-based 
computers deliver video with text or graphics overlay to the 
monitors. The headphones are driven by a third i486 
computer that handles speech synthesis and other audio 
feedback functions. This computer also handles voice 
recognition tasks, making use of the microphone. All three 
computers use ISA to VME bus adapters to communicate 
with the VMEbus. Video and audio signals from a remote 
robot are currently transmitted through dedicated channels. 

A chair platform includes control pedals and a 
transmitter for the HMD position sensor. Potentiometers in 
the pedals are powered and read by the same hardware used 
with the exoskeletons. Signals are also processed by the 
embedded i386 computer, and results are available on the 
VMEbus. The HMD position sensor transmitter has its own 
power supply and processor-based control box. 

An i486 embedded in the VMEbus serves as the 
command and control computer of TRIP. Through the 
VMEbus, this computer can communicate with all 
subsystems and coordinate their interactions. In addition, 
this computer handles all data communications with remote 
robots through an ethemet network board and a single 
dedicated cable. 

Software Architecture 

Figure 4 displays the current high-level software 
architecture. Software modules are shown in round-edge 
rectangles, and hardware is represented in square-edge 
rectangles. 
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The software architecture consists of control and 
configuration tasks, command routers, command handlers, 
bus data exchange drivers, RS-232 interface drivers, and 
TCP/IP network interface drivers. 

The control and configuration tasks reside on an 
embedded i486 computer in the VMEbus. These allow the 
operator to calibrate subsystems and define subsystem 
interaction rules. Control tasks coordinate the interactions 
between various subsystems. 

Command routers serve two functions. First, data are 
processed from input devices to produce specific subsystem 
commands. Second, these commands are routed to the 
appropriate subsystem message areas. Command routers 
are used with the voice recognition system and all motion 
input devices. 

Command handlers accept commands or messages 
from command routers and execute the commands or 
answer messages. Command handlers are used with output 
systems such as video and graphic overlays, speech 
synthesis, and environmental audio. 

Bus data exchange drivers allow commands and 
messages to be physically exchanged between the ISA 
buses and the VMEbus. Both embedded and external 
computers use these drivers 

Drivers for the RS-232 ports are used by the embedded 
i386 computer to communicate with the HMD position 
sensor controller. Commands can be sent to the controller, 
and raw orientation data are read. These raw data are also 
parsed and made available to bus data exchange drivers. 

Network access is provided by interface drivers using 
the TCP/IP protocols. These are used by the 
communication subsystem to transmit commands to or 
receive messages from a remote robot. They are also used 
to handle commands from TRIP subsystems and to route 
commands from the robot to the appropriate handlers. 

Software Tools 

Current software tools comprise two operating systems 
and three compilers. Windows 3.1 and iRMX are the 
operating systems, and they support development with 
Visual Basic (VB), Borland C++, and iRMX C. 

Windows 3.1 provides cooperative, event-driven 
multitasking with an easy-to-use graphical human interface. 
A large number of board-level drivers directly support this 
operating system and development through the system’s 
standard user interface. Windows 3.1 also provides a 
growth path to a 32-bit preemptive multitasking/ 
multiprocessing environment with Windows NT. Windows 
NT is backward compatible with 3.1 and uses the same 
graphical interface standards. 

iRMX provides 32-bit mode operation of the Intel 
microprocessors and real-time task scheduling for low- 
level, time-critical tasks. A unique feature of this operating 
system is its ability to run Windows as a task and 
communicate between the two operating systems. This 
enables the best of two worlds: 32-bit hard, real-time 
tasking and an easy-to-use standard interface. 


VB is an object oriented-visual development 
environment for the Windows operating system. Objects 
can send or receive messages, and events can be used to 
trigger user-developed code or operating system calls. The 
syntax is similar to that of Basic, but the code structure and 
object orientation endow it with many features found in 
C++. The visual development environment lends itself to 
very rapid prototyping of code and almost effortless user 
interface development. VB does not support some of the 
low-level capabilities found in C or C++, but Dynamic Link 
Library (DLL) functions written in C or C++ may be easily 
called. Operating system functions also may be called 
directly from VB. Dynamic Data Exchange (DDE), a 
client/server intertask communication protocol, is also 
supported and is easy to use. 

Borland C++ is an object-oriented C development 
environment that supports development for the Windows 
operating system. Specific to this project, it allows the 
development of low-level DLL functions, which may be 
called from VB code. Borland supplies an efficient code 
development environment with extensive debugging 
support. The object orientation promotes development of 
complete code modules, which are easy to reuse and build 
upon. 

iRMX C is a compiler and assorted tools for 
developing C-code task modules, which run in the iRMX 
real time operating system. These modules will 
accommodate time-critical, low-level functions as required 
by the TRIP. These functions may communicate with 
Windows-hosted code to report system status, alarms, or 
data needs. 

Floor Layout 

A planform view of TRIP hardware is displayed in 
figure 5. Shown are the chair platform, a 19-in. equipment 
rack, and two development work sites. An adjustable chair 
is mounted to the platform and serves as the operator 
worksite. Pedals, exoskeletons, and the HMD are all 
connected from the chair platform to equipment in the 
19-in. rack. The rack contains all TRIP computers along 
with audio and video ancillary equipment. Two 
development worksites each incorporate a keyboard, mouse, 
and two SVGA monitors. One worksite supports 
development on VMEbus subsystems, which include 
command and control, communication, and motion. The 
other worksite supports development on the audio and video 
subsystems. 

Subsystem Details 
Motion Subsystem 

The motion subsystem generates commands to control 
position or rate of all articulated members on a remote 
robot. Robot members include arms, hands, torsos, camera 
platforms, and mobile bases. The operator controls these 
using a combination of exoskeletons, foot pedals, and 
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position sensors. Force reflection and tactile feedback for 
the operator are planned as growth paths in the arm and 
hand exoskeletons of this subsystem. 

Current components of this subsystem are detailed in 
figure 6. It consists of an embedded i386 computer, an 
HMD position sensor, an A/D board with a signal 
conditioning box, exoskeleton arm and hand masters, and 
foot pedals. 

An embedded i386 based computer from the Radisys 
Corporation is used for subsystem processing and control. 

It runs at a clock speed of 25 MHz, contains 8 MB of 
DRAM, a keyboard controller, serial ports, and an ISA- 
compatible private bus that supports a 40 MB hard disk and 
a super VGA controller board. It boots with a PC/AT- 
compatible BIOS ROM and supports a number of 
operating systems. Radisys also supplies low-level 
functions that allow direct access to all VMEbus memory 
spaces. These functions are compatible with TRIP software 
tools. 

A Logitech 6D mouse is used to sense the HMD 
position and orientation. It makes use of an ultrasonic 
transmitter and receiver triangles to determine location in 
Cartesian space (x, y, z) and orientation (roll, pitch, yaw) as 
euler angles or quaternions. Also included is a dedicated 
control processor that communicates with the host processor 
via RS-232. Advantages of ultrasonics over magnetic 
sensors include reduced lag times and no interference from 
metal structures. A disadvantage is that the full range 
(0-360 deg) of euler angles is not supported, although TRIP 
does not require the full range for HMD tracking. 

A VMIVME 3118 scanning A/D board is used in 
conjunction with a signal conditioning board developed in- 
house to support 64 differential channels. The A/D board 
interfaces to the VMEbus via control registers and a dual- 
ported RAM data buffer. The signal conditioning board is 
housed in a separate box with a dedicated power supply. 

The board low pass filters (10 Hz) each channel and buffers 
the signal lines to the A/D board. It also supplies power to 
sensors on the exoskeletons and foot pedals. 

Two exoskeleton arm masters (EAMs) and two 
dexterous hand masters (DHMs) from Exos, Inc., are 
utilized in TRIP. The EAM provides precise measurements 
of human shoulder and elbow joint angles. Potentiometers 
are currently used to sense the angles. The DHM uses hall 
effect sensors to measure joint angles of the human hand. A 
GripMaster is integrated into each DHM to measure wrist 
motion. Development continues to be funded by NASA, 
with future objectives including the addition of sensory 
feedback in all areas. The current TRIP design will be 
capable of integrating these planned improvements. 

Foot pedals can be used to control robot torso and/or 
mobile base motion. In both cases, potentiometers are used 
to sense ankle joint angles that provide rate and directional 
control of robot motors. These pedals are attached to the 
chair platform. 

Software tasks running on the i386 read and process 
raw data from each of the input devices. One task reads a 
data buffer on the A/D board and processes for joint angle 


or rate commands. Processing includes some simple (i.e., 
boxcar) noise filtering and any required coordinate 
transforms. The A/D board continuously scans all active 
channels and updates the entire data buffer at about 800 Hz. 
A second task on the i386 reads and parses data from an 
RS-232 port to determine roll, pitch, and yaw of the HMD. 
This port communicates with the position sensor controller, 
which continuously updates position readings at about 
50 Hz. A third task on i386 accepts processed data from the 
other tasks and routes it to the appropriate command 
handlers (i.e., communication, graphic overlay, etc.) using 
bus data exchange drivers. 

Video Subsystem 

A video subsystem handles all live video signals along 
with any computer-generated graphics. Video is supplied 
by camera pairs on the remote robot, which are designed to 
provide stereo video to the human eyes. Computer- 
generated graphics and/or text may be calibrated to the 
video and overlayed to provide visual feedback, simulation 
results, or task tools to the operator. 

Figure 7 is a diagram showing half of the video 
subsystem. Each half feeds one of the operator’s eyes, and 
both halves are identical. Components include a helmet 
with HMDs, a video scan converter, a frame grabber and 
video compression board, an SVGA graphics board, an 
i486-based ISA bus computer, and ISA to VMEbus adapter 
boards. 

An HMD helmet from Virtual Research is currently in 
house. It incorporates headphones, the Logitech 6-D mouse 
receiver triangle, two color LCD displays (360 x 240 pixels), 
and wide-angle optics from Leep Systems. The helmet, 
designed for comfort, is extremely easy to don and doff. 

The Leep Systems optics have become an industry standard 
and can provide a field-of-view in excess of 100 deg. 
Currently available LCD displays do not have the resolution 
required to support the detailed video or graphics ultimately 
desired in TRIP. In response, work is progressing in house 
to develop higher resolution black-and-white HMDs that 
make use of wide-angle optics and flat panel CRTs. Other 
concepts for increased resolution and color are under 
consideration. 

The Genie scan converter from Jovian will accept 
60 Hz non-interlaced RGB signals (i.e., VGA at 640 x 480) 
as input and produce a 30 Hz interlaced NTSC signal as 
output. Monitors in most HMDs currently require an NTSC 
signal. In addition, the scan converter provides a gain 
adjustment and flicker filtering. Without the flicker 
filtering, certain horizontal lines appear to flicker and may 
contribute excessively to operator fatigue. 

The frame grabber and video compression boards are 
supplied by New Media Graphics, and both include low- 
level software drivers that are compatible with TRIP 
software tools. The frame grabber digitizes and scan 
converts live video from external cameras, allowing 
software manipulation of the images. In addition, this board 
will genlock and overlay (via graphics color keying) VGA 
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signals using a dedicated video (VESA) bus. The video 
compression board enables compression and decompression 
of full motion (30 Hz) video using a C-Cube CL550 JPEG 
chip. It supports storage, playback, and network 
transmission of video signals using a private video bus with 
the frame grabber. 

An Orchid Fahrenheit 1280° graphics accelerator was 
selected as the VGA board. It provides complete Super 
VGA functionality and makes use of a dedicated onboard 
processor to support graphics-intensive applications. Low- 
level drivers are included for the Windows operating 
system. 

Two i486-based computers are used for subsystem 
control functions and as graphics engines. Each runs at a 
clock speed of 33 MHz, contains 8 MB of DRAM, a 
keyboard controller, serial ports, and an ISA bus that 
supports a 210 MB hard disk and subsystem video boards. 
They boot with a PC/AT compatible BIOS ROM and 
support all TRIP operating systems. 

Bus adapters are supplied by Bit3 Corporation and 
provide a high bandwidth link between the VMEbus and 
ISA bus. Boards in each bus are linked with a shielded, 
multiconductor cable. The VMEbus board contains 2 MB 
of dual-ported RAM, which maps into the memory space of 
both buses. 

This subsystem accepts commands and messages from 
the VMEbus through the bus adapters. Software tasks 
running on the i486 computers are used to control the 
display of live video and to generate desired graphics or text 
overlays. Graphics can include wire frame models driven 
by simulations, and text may include voice menu selections 
or data from the remote robot. The video, graphics, and/or 
text are merged in the frame grabber and fed to the scan 
converter. This converter produces a filtered 30 Hz 
interlaced NTSC signal, which the HMD directly accepts 
and displays to the operator. Future HMDs with higher 
resolutions may directly accept the 60 Hz non-interlaced 
RGB signals, allowing scan converters to be bypassed. 

Audio Subsystem 

Speech synthesis, environmental audio, and voice 
recognition are all part of the audio subsystem. Speech 
synthesis provides TRIP an additional path for relaying data 
or messages to the operator. Environmental audio can be 
used to supply cues or feedback on the remote environment. 
This can take the form of actual environmental sounds 
(where possible) and/or computer-generated sounds that cue 
the operator. Voice recognition essentially replaces the 
keyboard as an operator input device and is required when 
the operator is wearing exoskeletons. 

Figure 8 diagrams the audio subsystem. Components 
include helmet-mounted headphones and microphone, a 
voice recognition system board, a speech synthesis board, 
an audio mixing system with an interface board, an i486- 
based ISA bus computer, and ISA to VMEbus adapter 
boards. 


The headphones and a microphone are part of the 
helmet assembly. Headphones are driven by an audio 
mixing system, and the microphone supplies audio signals 
to a voice recognition system. 

The voice recognition system was developed by 
Speech Systems, Inc. It provides continuous speech 
recognition, which is speaker independent, and includes a 
large vocabulary dictionary (about 40,000 words) that can 
be amended by the developer. A unique combination of 
speech encoding, acoustic frame compression, and linguistic 
decoding is used to support large, variable duration 
segments. 

Speech synthesis is provided by the DoubleTalk PC 
board and drivers from RC Systems. The board uses its 
own 10 MHz, 16-bit microprocessor and supports multiple 
speech technologies such as text-to-speech, LPC, PCM, 
ADPCM, and CVSD. The analog output can directly drive 
headphones or be directed through a mixing system. 

Audio switching, mixing, and signal processing are 
accommodated with a CDPC multimedia system by Media 
Vision. The system is based on the electronics of their Pro 
Audio Spectrum 16 and includes multiple audio input and 
output signal options. Signal processing includes digital 
filtering, tone control, bass enhancement, and signal 
equalization. The analog mixer supports volume control of 
each source, fade in/out, and audio panning. The system 
includes an ISA bus interface board and low-level drivers 
that are compatible with TRIP software tools. 

An i486-based computer is used for subsystem 
processing and control. It runs at a clock speed of 33 MHz 
and contains 8 MB of DRAM, a keyboard controller, serial 
ports, and an ISA bus that supports a 210 MB hard disk and 
subsystem audio boards. It boots with a PC/AT compatible 
BIOS ROM and supports all TRIP operating systems. 

A Bit3 bus adapter provides a high bandwidth link 
between the VMEbus and this subsystem. Boards in each 
bus are linked with a shielded, multiconductor cable. The 
VMEbus board contains 2 MB of dual-ported RAM, which 
maps into the memory space of both buses. 

The audio subsystem exchanges commands and 
messages with the VMEbus through its bus adapter. 
Software tasks running on the i486 computer handle 
commands for speech synthesis and environmental audio 
functions. Synthetic speech and environmental audio 
signals are processed and mixed by the CDPC system and 
then fed to headphones in the helmet. The operator’s voice 
is picked up by the microphone and fed to the voice 
recognition system for interpretation. Resulting commands 
are routed to the message areas of appropriate subsystems. 

Communication Subsystem 

The communication subsystem provides full duplex 
data transfers between TRIP and the remote robot using an 
ethemet-based network. Data can represent commands, 
sensory information, event messages, or requests for 
information. 
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Hardware for this subsystem is shown in figure 9. It 
basically consists of an embedded i486 computer from 
Radisys and an ethemet communications board* 

The i486 runs at a clock speed of 33 MHz and contains 
8 MB of DRAM, a keyboard controller, serial ports, and an 
ISA compatible private bus that supports a 210 MB hard 
disk and a super VGA controller board. It is operationally 
similar to the i386 controller of the motion subsystem and 
uses the same low-level drivers for VMEbus memory 
accesses. 

The ethemet board is Western Digital (8003EB) 
compatible and uses commonly available packet drivers. It 
also supports both thin and thick ethemet cables along with 
TCP/IP socket libraries. 

Software tasks running on the i486 computer serve 
three functions: (1) transfer data packets to and from the 
remote robot, (2) parse data packets and route information 
to other TRIP subsystems, and (3) handle commands from 
TRIP subsystems and build data packets. The data packets 
consist of structures that organize messages, commands, 
and information into a form that TRIP and the remote robot 
can both understand and easily parse. Future plans include 
incorporation of TelRIP software developed at Rice 
University. TelRIP (TeleRobotic Interconnection Protocol) 
is a layer built on top of TCP/IP with characteristics specific 
to teleoperation of robots. Other software tasks running on 
the i486 route messages to other TRIP subsystems. 

Command and Control Subsystem 

The command and control subsystem coordinates 
interactions of all subsystems with one another. It also 
serves as the focal point for system configuration and 
subsystem calibration efforts. 

This subsystem consists primarily of software but 
shares the embedded i486 used by the communication 
subsystem shown in figure 9. 

Software running on the i486 computer provides 
system-level arbitration of subsystem task and data 
interactions. These interactions may be defined in terms of 
the active communication paths between subsystems and 
the messages or commands understood on those paths. In 
addition, each of the other subsystems may be calibrated or 
adjusted from here to correspond to systems on the remote 
robot. Examples of this include mapping of exoskeleton 
joints to robot joints, definition of joint limits, activation of 
video targeting functions, and selection of environmental 
audio convolution methods. 

Closure 

The project described in this paper is primarily a 
system-integration effort. Architectures and approaches 
discussed are driven by a combination of operational needs, 
available technologies, and flexibility to incorporate 
projected technologies. Design goals included ease of use, 
configurational flexibility, and the inclusion of growth 


paths. These goals were constrained by cost and 
performance limits. 

Current Status 

All the basic hardware elements of TRIP are currently 
being integrated. Software tasks are either in the detailed 
design or implementation phase of development. The 
DART anthropomorphic target robot is currently in the 
implementation phase and will be interfaced to TRIP by the 
end of this year. The AERCAM free-flying target robot is 
in the detailed design phase of development. 

Future Work 

Future work will address the implementation and 
testing of newly developed subsystem and programming 
technologies. Examples in the video area include higher 
resolution black-and-white monitors, direct VGA interfaces 
with wide-angle optics, and computational graphics models 
as in reference 14. Motion control examples include the 
addition of force/torque reflection, haptic feedback, and 
teleprogramming concepts as described in reference 25. 
TRIP will also make use of 3-D acoustics research and 
signal processing techniques, such as those of reference 19. 
Robot communications will be enhanced through updated 
versions of TelRIP 20,21 software. Finally, an icon or block- 
diagram-based visual environment will be used for system 
configuration and subsystem calibrations. 
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Figure 1. Remote Robot Control Technology Spectrum. 




Figure 2. TRIP Subsystems and Technologies. 


Figure 3. Hardware Architecture. 
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An Intelligent, Free-Flying Robot for Crew Help and Crew or 
Equipment Retrieval in Space 
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Abstract 

The ground-based demonstrations of extravehicular 
activity (EVA) retriever, a voice-supervised, intelligent, 
free-flying robot, are designed to evaluate the capability 
to retrieve objects (astronauts, equipment, and tools) 
which have accidentally separated from the Space Station. 
The EVA retriever software is required to autonomously 
plan and execute target rendezvous, grapple, and return to 
base (while avoiding stationary and moving obstacles), 
with subsequent object handover. The software architec- 
ture incorporates a hierarchical decomposition of the 
control system that is horizontally partitioned into five 
major functional subsystems: sensing, perception, world 
model, reasoning, and acting. The design provides for 
supervised autonomy as the primary mode of operation. 

It is intended to be an evolutionary system, improving in 
capability over time and earning crew trust through 
reliable and safe operation. 

Presented here are an overview of the hardware, a 
focus on software, and a summary of results achieved 
recently from both computer simulations and air bearing 
floor demonstrations. Limitations of the technology used 
are evaluated. Plans for the next phase, in which moving 
targets and obstacles drive real-time behavior require- 
ments, are discussed. 

Introduction 

EVA crew rescue and equipment retrieval is a Space 
Station Freedom requirement. During the lifetime of the 
Space Station, there is a high probability that a number of 
objects will accidentally become untethered. Members of 
the crew, replacement modules, and key tools are fre- 
quently cited examples. The retrieval of these objects 
from space within a few minutes is essential. 

The Space Station cannot chase separated crew or 
equipment, even though crew safety is top priority. Other 
vehicles such as the Space Shuttle Orbiter or orbital 
plane-change vehicle will not usually be available. Real- 
time simulation of manned maneuvering unit (MMU) 
retrievals indicated that short response time was critical 
and that major risk to a second astronaut was involved, 
which was not acceptable. Equipment that might be used 
in retrieval may be too valuable to lose because it is 
required in operations and replacement is not available on 
the station. There is also collision potential on later 
orbits; though the potential is small, collisions have 
occurred previously. 

A potential solution is a supervised, intelligent, 
free-flying space robot. Supervised means here that the 


human chooses at the time and in the place of the opera- 
tion how the robot will perform as a team player. This 
adjustable autonomy depends on machine intelligence, 
which is the ability to achieve goals in the face of 
variabilities, difficulties, and complexities imposed by the 
environment. 

The free-flying space robot would operate near a 
spacecraft such as the Space Station in a primarily 
voice-supervised, autonomous mode for mobility and 
manipulation. The concept of supervised, intelligent, 
autonomous robotics provides for autonomous behavior 
of an intelligent type, normally controlled by humans at a 
high level of goal-setting and in mixed-initiative commu- 
nication. By contrast, telerobotics provides a partially 
automated remote extension of human task performance 
with occasional control delegation for specific parts of 
tasks given to the telerobot for efficiency reasons. 

Requirements call for an unassisted deployment from 
a mounting on the external part of the airlock, with 
propulsion capabilities provided by a more powerful 
version of the existing MMU. Performance guidelines 
include target retrieval within 120 minutes of subsystem 
deployment. Reliability considerations mandate the use 
of fault-tolerant and fail-safe designs with embedded fault 
detection and isolation capabilities. EVA retriever and 
crew would often cooperate in the same work envelopes. 
Safety, reliability, robustness, and maintainability in 
space are key attributes. 

The EVA retriever ground-based technology demon- 
stration 13 was established to design, develop, and demon- 
strate in three phases an integrated robotic hardware/ 
software system which supports design studies of a 
spaceborne crew rescue and equipment retrieval capabil- 
ity. Goals for 3 phases were established. 4 Phase I goals 
were to design, build, and test a retriever system test-bed 
by demonstrating supervised retrieval of a fixed target. 
Phase II goals were to enhance the test-bed subsystems 
with significant intelligent capability by demonstrating 
target retrieval with avoiding of fixed, arbitrarily oriented 
obstacles. Phase III goals are to more fully achieve 
supervised, intelligent, autonomous behavior by demon- 
strating retrieval of a moving target while avoiding 
moving obstacles. 

There have been recent developments in artificial 
intelligence (AI) planning and control techniques 5 ' 9 that 
make safe and reliable operations of supervised autono- 
mous robots possible. These techniques, known collec- 
tively as situated reasoning, tightly couple planning and 
execution through rapid and continuous sensing of the 
environment. These advances, as well as those in real- 
time perception, 10 show promise of achieving supervised 
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autonomous robotics that are safe and reliable enough for 
use in space. 

Presented here are an overview of the hardware and a 
summary of the Phase II results from both an orbital 
simulation and an air bearing floor demonstration. 

Problem Statement 

Space Station scenarios 11 were examined in some 
detail to aid in the definition of a set of design reference 
missions. A number of systems engineering studies were 
conducted in support of the software design. Level A 
requirements for a projected Space Station version were 
developed in a conceptual design study. 12 Level B 
software requirements were derived in greater detail for 
this possible future Space Station application. 13 

The EVA retriever software is required to 
autonomously plan and execute a target rendezvous, 
grapple, and return to base while avoiding stationary and 
moving obstacles. The design provides for supervised 
autonomy as the primary mode of operation. It is 
intended to be an evolutionary system, improving in 
capability over time and earning crew trust through 
reliable operation. 

The system is required to monitor plan execution, 
estimate probability of mission success, and dynamically 
replan when needed to achieve system goals. The mission 
profile requires appropriate actions for the following 
maneuvers: 

• Activation - Perform system health status and data base 
initialization. 

• Pop-up point rendezvous - Plan and execute a move 
with obstacle avoidance to one of a set of preselected 
pop-up points simulating movement away from the 
target obscuring environment near the Station. 

• Target acquisition - Plan and execute a target search 
(moving as required), identification, and determination 
of location. 

• Target rendezvous - Plan and execute a trajectory to 
near vicinity of one selected target object which avoids 
obstacles. 

• Grapple analysis - Plan and execute a grapple approach 
which allows vision based analysis of a grasp strategy. 

• Grapple - Plan and execute a one- or two-hand or arm 
(depending on target class) grasp using closed-loop 
vision control and force feedback sensors. Plan and 
execute maneuver of combined retriever/object to stable 
state for return to Space Station. 

• Handoff and deactivation - Plan and execute target 
handover at Space Station, retriever return to base unit, 
and deactivation. 

Approach - Phase II Prototype 
Phase II Hardware 

The current EVA retriever prototype (fig. 1) is an 
anthromorphic manipulator unit, with dexterous arms and 


hands, seated in an MMU. Sensor data include acceler- 
ometers, gyroscopes, two independent vision systems, and 
force/proximity sensors on the hands and arms. The 
accelerometers and gyroscopes measure the instantaneous 
translational and rotational acceleration/rate of the EVA 
retriever. The primary vision system consists of a laser 
scanner imager (128 x 128 pixels of both range and 
gray-scale intensity) and a camera mounted on a control- 
lable turntable. The turntable provides for ±180 deg. 
rotation at 5 deg/s. The secondary vision system is a 
multicamera video imaging system, with a 3 chest-camera 
array. 

The MMU has twenty-four thrusters, four on each 
rectangular side. These thrusters provide a fixed force in 
three perpendicular translational directions and a fixed 
torque in each of the three perpendicular rotational 
directions. The MMU accepts simple translation and 
rotation on/off command to fire thrusters to provide fixed 
acceleration in any of the three translational or three 
rotational directions. The EVA retriever weighs approxi- 
mately 1100 lbs with each thruster providing approxi- 
mately 1.75 lbs force. A translation command to the 
MMU results in approximately 2.6 in/s/s acceleration in 
the commanded direction. A corresponding rotation 
command results in a rotational acceleration of roughly 
3 deg/s/s. 

The current technology demonstrations are being 
conducted on the JSC Precision Air Bearing Floor 
(PABF). The retriever/MMU unit is mounted on a test 
stand with compressed air supplied through an umbilical. 
Thus, the test unit is constrained to x, y, and yaw motion. 
The prototype has dual 6-degree-of-freedom arms with 
roll and pitch at the shoulder, elbow, and wrist. One of 
the arms has a compliant grasping hand and the other has 
a 3-fingered dexterous hand. The right hand incorporates 
proximity sensors in order to support compliant grasping 
of an object with force limiting. 

The processor configuration contains two 15-MHz 
T414 transputers, twelve 20-MHz T800 transputers (five 
of which are dedicated to vision processing), a 16-MHz 
80386, and six 68020 controllers. The transputers and 
68020s are programmed in C and the 80386 is pro- 
grammed largely in LISP. 

Phase II Software 

Based on the previously mentioned analysis of Level 
A and B software requirements projected for Space 
Station, a set of Phase II Level B software requirements 
was developed 14 as were Phase II PABF scenarios. 

The software architecture incorporates a hierarchical 
decomposition of the control system that is horizontally 
partitioned into five major functional subsystems: 
perception, world model, reasoning, sensing, and acting 
(fig. 2). In traditional hierarchical software architectures, 
the flow of messages and data through the command tree 
is strictly enforced with no horizontal flow. A disadvan- 
tage of this architecture is that bottlenecks may develop 
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due to lack of horizontal communications between 
components at the same level. The design presented here 
utilizes hierarchical flow of command and status mes- 
sages but allows horizontal flow of data between compo- 
nents at the same level. Computation is performed at the 
lowest possible level and, in general, knowledge-based 
systems are utilized only when algorithmic solutions are 
lacking in power or flexibility. This approach handles 
multiple levels of abstraction well and permits the 
incorporation of special data paths between time-critical 
components. 

The state perception module estimates the dynamic 
state of the EVA retriever (translational and rotational 
position and velocity). State estimation is based on 
measurements from the accelerometers, the gyroscopes, 
and a camera. These measurements provide information 
on translational acceleration and rotational velocity at 
100 Hz, and updated relative position vectors to objects of 
known position at approximately 0.5 Hz. 

The world model provides a representation of the 
external environment and internal status that is 
three-dimensional in space and dynamic in time. It 
contains a variety of general world knowledge as well as 
specific mission-related facts and constraints. The world 
model maintains over time the identity of the objects 
instantaneously sensed by the vision subsystem and 
provides notice when new obstacles or targets are 
detected, supplying a consistent model of the environment 
for the purposes of navigation. 

The reasoning functions of the system are partitioned 
among the mission control and assessment, the action 
arbitrator, and the planning modules. 

The mission control and assessment component 
directs the development and execution of a mission plan 
with supervisory direction from a human controller. 
Commands are received from the operator through a voice 
recognition processor with confirmation via voice 
synthesis. The module acts primarily as a plan execution 
monitor and as a meta-planner, delegating the creation 
and execution of detailed plans. Cue action modules, 
which look for specific events to occur in the world, 
initiate a wide range of monitoring, planning, and control 
actions. An internal assessment module initiates replan- 
ning whenever an expected cue fails to appear within a 
reasonable period of time. Also, replanning is initiated 
when a cue is triggered reflecting a change in the environ- 
ment (e.g., a new obstacle) in the planned path. 

The planning module consists of five functional 
components: vision, speech, motion, manipulator, and 
reconfiguration. For the current technology demonstra- 
tion, the speech and reconfiguration planning components 
were not implemented. 

In general, the planning module responds to requests 
from the mission control and assessment component, 
issues data requests to the world model, and sends plans 
and status information to the world model. The total set 
of action primitives available to the planning module is 


based on the action requests recognized by the hand/arm, 
MMU, and the camera turntable subsystems. 

The motion planner calculates a grid-based transition 
cost field based on safety zone and world model estimates 
of target/obstacle (fixed) location and size. The transition 
cost field is dynamically updated in response to changes 
in obstacle location or number. The path is constructed of 
straight line segments with node location determined by a 
change in direction or the need to maintain the target/ 
body orientation required by the vision system. 

The vision planner constructs motion plans which 
support vision processing such as a search for an obscured 
target or positioning of the retriever for an analysis of a 
target grapple. The module maintains internal models of 
the vision sensor’s field of view given obstacles and plans 
a move to see the most probable part of a target region 
which has not been previously observed. 

The manipulator planner handles gross hand/arm 
positioning for grappling based on target type. Small 
targets are grasped with one hand, medium size targets 
with two hands, and targets the size of an astronaut are 
grappled in a bearhug using both of the retriever’s arms. 

The action arbitrator is the primary interface between 
the reasoning and action subsystems. Under the supervi- 
sion of the mission control and assessment module, plan 
fragments are retrieved from the world model and 
transmitted to the appropriate action subsystem interface. 
Depending on the subsystem, actions may be occurring in 
both a serial and a parallel manner. 

The motion control module accepts motion com- 
mands generated by the planning module and/or the 
mission control and assessment module. Commanded 
motions basically include a translation to a desired 
position and/or a rotation to a desired orientation. The 
motion controller uses the state estimation provided by 
the state perception module as control feedback. The 
motion controller uses the MMU propulsion system to 
control the position and attitude of the body. 

Approach - Phase II Environments 

Precision Air Bearing Floor (PABF) 

PABF was used in Phase II for integrated testing and 
demonstration. This 24 x 32 ft floor is composed of metal 
plates which are laser-levelled to approximate a perfectly 
smooth surface with error of < .005 inches. The retriever 
hardware is levitated off this surface by supporting pads 
releasing pressurized nitrogen. The lights on the ceiling 
above the PABF eventually played a critical role: A 
camera facing the ceiling was mounted on the retriever to 
track the lights and compute a correction for the 
retriever’s position and attitude estimate in analogy to 
using the global positioning satellites in space. 

Before integration and testing on the PABF, the 
software, with the exception of the one-handed tool grasp, 
was integrated and tested in a simulated PABF 
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environment. The following elements were simulated: 

(1) acceleration of the retriever due to minute slopes on 
the PABF, (2) idealized output of the vision system for a 
given set of objects on the PABF (position, radius for 
navigation, orientation for grasping), (3) turntable rotating 
the laser range imager, and (4) manipulator kinematics 
and motion assuming constant joint angular velocities. 

The unsensed changes in location due to the 
imperfections in the PABF were significant because the 
onboard accelerometers do not measure gravitational 
acceleration. A simulated corrective measurement of 
retriever position was developed to test motion control 
alternatives with various assumptions about how this 
correction would be implemented. 

This simulation was used primarily to integrate our 
distributed software modules and preliminary test 
execution of the various mission phases under a variety of 
conditions while the hardware itself was being assembled. 

Orbital Simulation 

An integrated dynamics simulation of the current 
EVA retriever hardware in an orbital, Space Station 
Freedom-based environment has been developed. 15 This 
simulation includes models of the 6-degrees-of-freedom 
dynamics of orbiting bodies, the Odetics laser scanner 
range imager, the MMU dynamics and plume 
impingement, scanner turntable, and trivial manipulator/ 
target capture logic. Failure modes in the manipulator/ 
target capture logic have been implemented, as has the 
ability to freeze the simulation and alter the positions/ 
velocities in both translation and rotation for all the 
bodies in the simulation. 

This simulation provides a capability to allow 
development and evaluation of various software 
technologies such as situated reasoning and those which 
will be needed to deal with moving objects and a 
dynamic, unpredictable environment. 

Phase II Results - PABF 

The system capabilities described earlier have all 
been demonstrated. These include retrieval of 2 types of 
targets: (1) a small “wrench” which will fit inside the 
Jameson dexterous hand, and (2) a large astronaut-sized 
cylinder which can be enclosed by the EVA retriever 
body/arms. The targets may be initially obscured and 
arbitrarily oriented, given the degrees of freedom 
available to the retriever and the constraints of the target 
supporting stands. An operator provides (1) direction to 
target, (2) target identification based on image display, 
and (3) notification if the target is obscured. Retrievals 
may be accomplished in 7 to 15 minutes, depending on 
degree of difficulty. Fuel is available for 200 ft of travel. 
Unique and special aspects of the retriever are 
summarized in table 4. 


Self-Location 

One aspect of PABF simulation-based testing in 
Phase II bears discussion: the failure to detect a software 
design flaw because of low fidelity in the simulation. The 
undetectable accelerations due to minute slopes on the 
PABF and the need to correct this via some other 
measurement source have been mentioned. The initial 
approach was to infer the retriever’s position from 
objects’ positions determined through laser-scanner-based 
vision. The vision algorithm used was a simple one: after 
the image has been segmented, each object’s position 
would be computed as the average of all its range pixels; 
i.e., centroids. These positions would be passed to a 
tracking algorithm which would match them, if possible, 
to objects already seen. The difference in their positions 
would represent movement of the retriever itself because 
the objects were stationary. The simulated system was 
not tested with noise in the centroids, and the system 
worked fine. Once we began integrated testing with the 
hardware, we found this method to be unworkable. 
Ultimately, a correction method based on a camera 
tracking overhead light was adopted. 

Target Acqulsltlon/Tracklng 

Objects’ size and location are perceived 
dynamically — only the retriever’s position is known 
initially. An operator is used to identify the target, 
although testing of model-based recognition showed 
promise (it was limited by sensor noise). Finally, the 
laser scanner limits the targets to those with high 
reflectivity. 

Navigation 

Navigation, rendezvous, and stationkeeping are 
completely autonomous. Paths are executed at speeds of 
0.375 ft/s in translation and 8 deg/s in rotation. 

Translation is limited by PABF size (24 ft x 32 ft) and 
MMU acceleration (< 7 lb/s). While following paths, the 
position deviates by < 3 to 4 in (combination of position 
est. error + pos. control) and the attitude deviates by 
< 3 deg. Path generation is based on minimum distance. 
Objects are assumed to be stationary and symmetrically 
shaped (they must occupy or not grid cells). If target is 
not visible to the retriever, it plans a path to the largest 
obscured space in target direction. The scanner faces the 
direction of motion continuously. 

Target Grasping 

Target grasping is completely autonomous as well. 
The target is assumed to be stationary. Computer vision 
algorithms were tested against oddly shaped objects, but 
weren’t robust in target orientation due to sensor noise. 
Because the target is stationary, the manipulator(s) path 
could be followed at any speed — Remotec arms took 
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roughly 5 seconds for reach. “Trajectory” planning 
wasn’t necessary, and the control was not closed loop 
relative to the target, for the same reasons. Finally, the 
size of the target for single-handed grasping was limited 
to those that fit within the size of the Jameson hand 
(largest opening is 5 in). Error in positioning the arms is 
estimated at 1 to 4 in, limited by Remotec joints accuracy. 
The dexterous hand is commanded to close when the 
target trips a proximity sensor in the hand and stops 
closing when a fixed level of force on the target is 
measured. The two-armed grasp is terminated by 
pressure sensors in arms and chest. 

Phase II Results - Orbital Simulation 

This simulation has been used to develop software 
for MMU orbital control, model-based object pose and 
motion estimation, and situated reasoning and reactive 
planning. The reactive planner, developed by Advanced 
Decision Systems (ADS), 7 provides logic for continuing 
the retrieval mission despite the occurrence (at any 
appropriate point in the mission) of one of the failure 
modes mentioned in section 4. These include losing track 
of the target, having the EVA retriever or target moved 
prior to capture, “accidentally” dropping the target after 
capture, etc. This enables the retriever to react in real 
time to dynamics of its environment, act to acquire 
knowledge, act on beliefs, react to failed expectations, 
and act predictively by reasoning about dynamics. A 
demonstration video of the retriever reactive planner in 
this 6-degrees-of-freedom simulation has been produced. 

Conclusions 

Robotic technology has been evaluation for practical 
application to retrieval of detached crew and equipment in 
space. The completed phase described here comprises an 
initial attempt to build and understand a limited version of 
a supervised autonomous robot for use in space. 
Supervised intelligent systems, including supervised 
autonomous robots, also need to be developed for Earth 
applications. 16-18 

Phase III, during which moving targets and obstacles 
drive real-time behavior requirements, will also explore 
crew helper tasks. Table 2 lists tasks and possible 
capability improvements. Evaluation of real-time vision 
and moving object grasp with new, faster equipment is 
planned for the KC-135 reduced gravity aircraft in 1993. 
Recent work 19 * 20 offers promise that safe and reliable 
space robotic systems can be achieved. Recent studies 21 
show that such systems will be useful on planet surfaces 
as well as being needed in orbital applications. 
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Table 1. Unique and Special Aspects of EVA Retreiver 


Is a prototype supervised, intelligent, autonomous 
robot 

Responds to voice commands providing goals and 
directions 

Clips into spaceworthy MMU which has flown from 
Shuttle 

Flies by propelling pressurized gas from MMU 
thrusters it controls 

Can determine its own location with camera, 
gyroscopes, and accelerometers, in analogy to 
space use of global positioning satellites 

Builds its own internal dynamic knowledge of its 
environment based on continuous sensory 
perception (no preprogrammed environmental 
model to which the environment must conform) 

Plans/replans based on goals and internal dynamic 
knowledge of its environment and constraints 
such as flight rules 

Path planner for obstacle avoidance and rendezvous 
can reason in advance about the success of the 
mission 


- Actions are synchronized to events in the world 
through sensing of preconditions of planned 
actions 

• Location of range image obstacles and target 

tracking, orientation, and grasp location 

• Acts to acquire knowledge about obscured target 

• Maneuvers to optimize grasp success relative to 

target orientation 

• Chooses between one- and two-handed grasp or 

two-armed grapple, depending on target size 

• Dexterous grasping uses proximity sensors, 

compliant grasp, and force-limited grasp 

- Right hand has five proximity sensors 

- Left hand has three proximity sensors and nine 
tactile sensors (three per finger) 

• Pressure sensors on chest used in two-armed grapple 

of large targets 

• Uses fourteen 10 million instructions per second 

(MIPS) transputers, six 68020 controllers, and 
one 80386 processor in a hierarchical, distributed 
architecture 
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Table 2. Phase III Plans 


Tasks and Environments 

• Crew helper tasks 

- Moving obstacle avoidance and moving target 
rendezvous 

- Grasping translating and rotating objects 

- Retrieving objects from storage or current 
location 

- Returning objects to storage 

- Inspection 

- Assistance in holding objects 

- Maintenance site preparation 

- Orbital replacement unit exchange 

• Environments 

- Vicinity of Space Station via computer 
simulation 

- PABF with spacecraft mockup 

- Laboratory testing 


Improved Capabilities 

• Model-based object recognition and motion 

description 

• Situated reasoning/reactive planning to dynamics 

of environment 

• Speech recognition and limited natural language 

understanding 

• Guarded, compliant, and fine motion manipulation 

• Knowledge representation of objects, event, 

processes, and states of affairs 

• Internal knowledge of competencies 

• Fast 7-DOF manipulator 

• Faster frame rate laser range imager 

• 200 MIP/25 Mflop transputers enable computer 

hardware and software to all be packaged on 
board 

• Self-contained hand design 

• More effective use of tactile sensors 









Figure 2. EVA Retriever Software Components. 
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Abstract 

This paper describes a computer simulation program 
that has been developed to analyze the reliability and 
maintainability of the Space Station Freedom (SSF). The 
program is a stochastic, event-oriented simulation process 
written in FORTRAN and implemented on a personal 
computer. The program which simulates hardware fail- 
ures as well as preventative maintenance tasks, uses user- 
specified maintenance resources to perform maintenance. 
TTie program has the capability to interface dynamically 
with Space Station function minimal cut sets in order to 
determine queuing priorities and to assess the status of 
Space Station functions. This model, the Reliability and 
Maintainability Assessment Tool (RMAT), is being used 
as a program-wide resource for predicting maintenance 
levels for the Space Station. It is also being used by the 
Reliability and Maintainability Division to assess the 
functional capability of Space Station. 

Introduction 

NASA’s SSF is a complex, long-term project 
containing numerous components which may require 
maintenance one or more times over the expected life of 
the Station. NASA must be able to accurately assess the 
maintenance needs of the Station in order to determine the 
feasibility of the current design and to monitor the results 
of design changes and Station restructuring. The SSF 
RMAT is a stochastic, event-based simulation program 
designed to predict the maintenance needs of the Space 
Station and to assess the availability of Space Station 
functions. Development of the RMAT began in the 
summer of 1990, and it was first used for Space Station 
analysis later that summer. Additional analysis capability 
has been added to the RMAT as additional Station data 
have become available. 

Description 

The RMAT is a stochastic simulation program 
written in FORTRAN and implemented on a personal 
computer. Figure 1 shows the general flow of the 
program. Input to the program includes component 
reliability and maintainability (R&M) data, function 
reliability block diagrams or a functional criticality level 
for each component, and maintenance resource levels. 

The reliability data are used to simulate maintenance 
action demands such as equipment failures, preventive 
maintenance tasks, and induced failures. Hie reliability 


block diagrams or the criticality levels are used to 
evaluate the impact of the failures and determine the 
queuing priorities. Hie maintainability data and the 
maintenance resources are used to simulate the 
performance of maintenance. Program output includes 
predictions for the number of maintenance actions and 
hours by time period, the availability of Space Station 
functions, maintenance demand by location, and 
maintenance demand by type of component. 

RMAT can use two methods to assess the impact of 
the failure to determine queuing priorities. When 
available, cut sets generated from reliability block 
diagrams of the functions can be used to determine 
queuing based on functional criticality and the current 
level of redundancy. This allows assessment of the 
availability of the functions. When reliability block 
diagrams are not available, functional criticality levels are 
used to queue components. 

The program is large enough to handle the entire 
station (up to 16,000 components) so that the competition 
for crew resources can be accurately modeled. The 
program gives the user the ability to perform trade studies 
on the maintenance resource levels and the configuration 
of the functions to optimize the availability of the Station. 

Methods 

Failure Generation 

Failure modeling is done using a Monte Carlo 
simulation approach. To simulate each time to failure, a 
uniformly distributed random number between 0 and 1 is 
drawn and is set equal to the reliability function for that 
component. Time to failure is calculated by solving this 
equation. This is done individually for each modeled 
component. 

The failure rate is assumed to be three components: 
random failures, early failures, and life-limit failures. The 
random failure rate is assumed to be constant and is 
modeled as an exponential time to failure function. The 
duty cycle (operating ratio) of each component is factored 
into the random failure reliability equation. This equation 
also includes failures while the equipment is off or 
dormant. Component input data include a cold failure 
rate factor which is the ratio of the cold failure rate to the 
hot failure rate. 

The early failure rate is considered as a time-varying 
modification of the random failure rate. This 
modification causes the failure rate to begin at a higher 
level than the constant, random failure rate, and then to 
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decrease fairly rapidly over time as the infant mortality 
rate decreases and reliability growth occurs. Use of this 
early failure/reliability growth modification curve is 
optional. 

The third component of the failure rate is the life- 
limit, or wearout, component. This is modeled with a 
two-parameter Weibull distribution. 

Failure rate multipliers, called K-factors, are used to 
account for maintenance actions which occur for reasons 
other than the inherent component failure. K-factor 
values are assigned to components by category and have 
default values which are currently determined by a NASA 
working group. Components are categorized for K-factor 
purposes as being electrical, electronic, mechanical, 
electromechanical, structural, or structure-mechanical. 
Separate K-factors are also assigned for internal and 
external hardware. A K-factor is composed of four terms: 
Kj, human-induced; K^ environment-induced; K^ 
equipment-induced; and K 4 , no defect or false alarm. 

The RMAT also allows for three types of 
preventative maintenance: preventative remove and 
replace, servicing, and inspection. The times between 
preventative maintenance are not randomly distributed by 
the RMAT but are scheduled to occur at fixed intervals of 
time as supplied in the component data file. The failure 
of a component will cause all preventative maintenance 
for that component to be removed from the event calendar 
or queues. A preventative remove and replace being 
performed or placed in the queue will also clear other 
types of preventative maintenance from the event 
calendar or queues. 

Evaluation of Failure Impact 

When a component failure occurs, a decision must be 
made regarding prioritization of the repair of the 
component. There are eight priority level queues 
available for use in the program. Within a single queue, 
tasks are time-ordered with the longest jobs having the 
highest priority. 

When functional reliability block diagrams are 
available, minimal cut sets which are generated from the 
reliability blocks diagram via an off-line software 
package can be used to dynamically monitor Space 
Station functions. In this case, queuing of components is 
based on functional priorities and the redundancy 
remaining in that function at the time of the failure. 

When reliability block diagrams are not available, 
components are queued according to a predefined input 
criticality level. The user assigns queuing priorities 
separately for corrective and preventative maintenance 
through file input. Queuing by functional criticality level 
rather than by reliability block diagrams, however, does 
not account for redundancy. Both the maintenance 
performed and the maintenance backlog are reported by 
queue. 


Performing Maintenance 

Maintenance task time consists of two parts: the 
worksite time and the maintenance task overhead time. 
The worksite task time includes only the actual time to 
perform the maintenance action itself. The overhead time 
includes the time necessary to obtain the spare part and 
necessary tools, to travel to the worksite, and to set up the 
worksite. 

A lognormal distribution with a 95th percentile equal 
to three times the given mean is used to simulate the 
variability in maintenance task times. Both the worksite 
time and the overhead time are randomly distributed 
according to this lognormal distribution. The mean time 
to repair (MTTR) and the overhead category for each 
component are supplied in the component input file. The 
time values for each overhead category are supplied by 
user input. Because of the modular construction of the 
program, other distributions can be easily substituted. 

Both internal and external maintenance is packaged 
into shifts of work. A certain amount of overhead is 
associated with performing maintenance, particularly 
external maintenance. This overhead, which is called 
sortie overhead, is charged once per maintenance shift. 
Packaging the maintenance into shifts reduces the impact 
of sortie overhead. 

No task will be started by the program unless its 
predicted maintenance time is less than the time 
remaining in the shift. Therefore, some shifts may end 
early because no maintenance actions are in the queue 
which would fit into the time remaining in a shift. Due to 
the lognormal distribution of maintenance task times, 
some tasks may run beyond the planned end of a shift. 
According to current NASA flight rules, external 
maintenance may only run fifteen minutes over the 
scheduled time. A job not completed during this time 
must be redone later. 

To allow maintenance to be packaged into shifts, a 
maintenance threshold is used. The maintenance 
threshold is a minimum backlog of crew maintenance 
hours which must accumulate before maintenance is 
triggered. Separate thresholds exist for EVA and IVA 
maintenance. Both thresholds may be set by the user. 
When crew maintenance resources become available, 
maintenance is performed based on the queue priorities 
and the maintenance threshold for as long as maintenance 
resources still exist. 

Maintenance resources are specified in two phases, 
the assembly phase and the postassembly phase. During 
the assembly phase, the resources can change with each 
Shuttle flight. Once assembly is complete, however, the 
resource levels are assumed to be constant throughout the 
life of the Station. Resources can be from the Station 
crew, from the Shuttle crew, or from Station or ground- 
controlled robots. Separate resource levels are specified 
for internal, external, and robotic maintenance. 
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Results 


Extendibtlity 


The RMAT program is currently used by the Space 
Station analysis community for maintenance prediction. 
Users include the external maintenance solutions team, 
the in-flight maintenance working group, and the internal 
maintenance task team. The RMAT is also used to 
generate crew worksite time predictions included in the 
NASA Level II Resource Margin Summary Document. 
These users have utilized the RMAT, without cut sets, to 
assess predicted levels of maintenance demand for the 
SSF and to assess levels of maintenance backlog due to 
constrained resource levels. The SSF Program has now 
identified functional criticality levels for almost all of the 
components. By assigning different criticality levels to 
different queues and by examining the maintenance 
backlog by queue, the user can assess the impact of the 
backlog by functional criticality level. 

An example of the extravehicular activity (EVA) 
maintenance demand for Work Package 2 during the 
assembly phase is shown in figure 2. These results were 
generated with some preliminary SSFP R&M data and 
should not be considered as actual or approved 
predictions of SSF maintenance needs. Early failures 
were not considered for this run. The figure shows a 
distinction between those items on the minimum 
equipment list (MEL) and those items not on the MEL. 
Because flights during the assembly phase are not equally 
spaced in time, the figure has a sawtooth look. 

Analysis Capability 

It is necessary to develop the capability of assessing 
the availability of SSF functions resulting from the 
maintenance backlog. RMAT may be used to determine 
availability if all the Station functions are modeled with 
reliability block diagrams. However, to date, only a few 
Station functions have been modeled with reliability 
block diagrams. 


The program is modular in nature and can be 
extended and modified as the need arises. One of the next 
planned extensions is the addition of overhead 
calculations for robotic maintenance. Data to support 
such calculations have not existed in the past, but are 
expected to become available during the Spring of 1993. 
The RMAT will be modified to accept this data. Other 
examples of model components that can be modified 
include the early failure mechanism and the maintenance 
time lognormal distribution. In-house tests have been 
done using other distributions or algorithms in the RMAT 
which have proven quite easy to implement. 

Summary 

The RMAT is a viable analysis tool for the Space 
Station. Its success has depended on keeping the level of 
modeling detail consistent with the availability of the SSF 
data. 

A number of significant factors are not included in 
the RMAT program, for example spares and mission 
operations, but at this point in the development of the 
SSF, the RMAT tool appears to be the best available 
predictor for Station maintenance. It is essential that the 
SSF Program be adequately prepared to handle this 
expected level of maintenance. Recognizing the levels of 
maintenance that will be required will help the logistics 
and mission operations areas plan for the provision of 
adequate levels of SSF support. 
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Figure 1. RMAT Program Flow. 
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Figure 2. Work Package 2 External Maintenance Demand During the 
Assembly Phase. 
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Abstract 

The Reliability and Maintainability Division within 
the Safety, Reliability and Quality Assurance Office at 
JSC uses the reliability and maintainability assessment 
tool (RMAT) to simulate future failures and repairs of the 
Space Station Freedom (SSF) components and to assess 
possible maintenance scenarios associated with the SSF 
Program (SSFP). The RMAT is also used to generate 
measures of the projected availability of critical functions 
of the SSF during and after assembly. It must, therefore, 
be capable of simulating the assignment of repair 
priorities for items requiring repair, and of evaluating the 
impact of the nonrepaired items as a function of time. 

This capability exists, in part, in a RMAT version that 
uses cut sets (equipment/component failure combinations 
that will fail critical SSF functions). During the 
permanently manned configuration (PMC) phase, the 
probability of the failure of these functions can then be 
estimated. Reliability and availability assessments during 
the assembly phase, however, are more difficult because 
they require the use of system and functional hardware 
configurations that change with time (i.e., time dependent 
cut sets). A new version of RMAT was developed to 
address this situation. This paper discusses the overall 
RMAT analysis approach and describes the version of 
RMAT that was developed to better assess the SSFP 
safety, reliability, and maintainability characteristics 
during the assembly phase of the Program. 

Introduction 

The previous standard RMAT version 3.2 was 
created so that the reliability and availability of a SSFP 
function, such as attitude control, could be evaluated 
based on the reliability block diagram configuration of the 
function. The RMAT 3.2 performs this task by using cut 
sets of the function as input. These cut sets are generated 
from reliability block diagram analyses (RBDA) efforts 
and represent equipment/component failure combinations 
that will cause the associated SSFP function to fail. 

When a component fails, the program reviews the cut sets 
to determine the status of the function after the 
component failure. The function status is dependent on 
the redundancy level remaining after the failure. If the 
failure causes the function to fail, then the function status 
becomes red (not available). The item which caused this 
condition is put in the highest priority queue, with its 
repair becoming the most urgent. If this failure results in 
one level of redundancy remaining, the function status 


becomes orange; two levels of redundancy, the status 
becomes yellow; and three or more levels of redundancy, 
the status becomes green. The orange, yellow, and green 
statuses result in successively lower priorities of repair 
queues. When a component is repaired, the function 
status is reevaluated and reset, again, depending on the 
redundancy level of the function. All those items in the 
red queue are repaired prior to those in the lower priority 
queues. 

The RMAT 3.2 keeps track of the amount of time a 
function spends in each of the four possible states (colors) 
and at the completion of a run will print these as 
percentages of the total simulated mission time. For 
example, the program could be run for a simulated 
mission period of 10 years with an input attitude control 
function (ACF) hardware configuration reflecting the 
expected configuration of the SSF after mission build 
(MB) six. In this case, the results could show that the 
ACF was in the red for 6 months out of the total 120 
month period, and the RMAT summary report would 
indicate a red ACF condition (not available) 5 % of the 
total mission period. The RMAT 3.2 also tracks the 
number of times that the function was in the red, or how 
many times the function went down. This counter is 
necessary for calculating the probability of success for the 
function. 

Problem 

In an initial study, the RMAT 3.2 was used to 
determine the reliability and availability for different MB 
configurations of the SSFP ACF. The elapsed time 
between the completion of a specific mission build flight 
and the following Shuttle flight was varied from 30 days 
to 180 days. Figure 1 depicts how the ACF reliability 
decays as the delay between Shuttle flights is increased 
after the completion of four MB configurations 
(MB 2, 4, 5 and 6). The decreasing availability function 
for the same conditions is depicted in figure 2. The only 
conclusions that could be drawn from this analysis were 
relative to the maximum Shuttle flight intervals between 
the MBs and the associated ACF availability. One of the 
restrictions of this analysis was that the RMAT 3.2 made 
the assumption that all SSFP components were operating 
properly at the start of each of the MB phases under 
consideration. Thus, no carryover (backlog) of 
unrepaired failures from a previous assembly phase was 
possible. In order to eliminate this restriction and to 
produce a realistic availability analysis, a modification of 
the RMAT was completed. 
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Approach 

A dynamic RMAT was developed (version 4.2) with 
the capability to track failures from MB to MB and to 
update the system hardware configuration at any time. 
That is, at the start of a new assembly mission, those 
components from the previous build which had failed are 
carried forward and are used to produce system status 
from the effects of the component failures on the next 
assembly flight. The components from the previous 
failures which caused the function status to be red will 
have the highest priority for repair purposes and will 
remain red until the appropriate components are repaired. 
This analysis tool yields more appropriate assessments of 
the risks and survival probabilities of the SSFP during the 
assembly phase. 

The RMAT 4.2 yields the same output as the RMAT 
3.2 but with additional results on a assembly-flight-by- 
assembly flight basis. That is, the summary report gives 
the percentage of time and the number of times the 
functions, such as the attitude control function, were in 
the four states (colors) while the SSFP was in a specific 
hardware configuration. The RMAT 3.2 assumption that 
all components are up and running at the start of a run is 
no longer necessary. 

The RMAT 4.2 is able to perform multiple runs with 
up to 170 different Space Station configurations (a 
maximum of 10 different functions and up to 17 assembly 
flights for each function). As the program executes, it 
constantly updates the configuration of each function and 
then determines the status of each function based on those 


components which have failed. Hence, as the assembly 
phase progresses and the configuration changes, the cut 
set information that the RMAT uses to determine the 
reliability effects is modified accordingly. 

Results 

Modifications reflecting the RMAT version 4.2 are 
complete. Testing and verification are presently 
underway with the utilization and reporting of RMAT 4.2 
analyses planned before SSFP Critical Design Review in 
April of 1993. The critical functions of attitude control, 
reboost, and mating as a function of assembly through 
MB-6 were completed in April 1993. The RMAT 4.2 
analysis of the SSF availability of these functions was 
completed in April 1993. 

Conclusions 

The RMAT version 4.2 provides a more accurate 
assessment of the survival and risk probabilities of the 
SSFP during the assembly phase. Analyses and results 
were addressed during the SSFP Critical Design Review. 
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Figure 1. MB2, MB4, MBS and MB6 ACF Reliability. 
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Figure 2. MB2, MB4, MBS and MB6 ACF Availability. 
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Abstract 

Expert systems (ESs) technologies have 
demonstrated the capability of solving a diverse range of 
problems. However, in operational or mission-critical 
environments, they have achieved only limited 
acceptance. Because software engineering methods were 
not used in their development, ESs have met with limited 
acceptance and an overall lack of confidence in their 
technologies. More specifically, the need for verification 
and validation (V&V) during ESs development was 
identified as a major factor. Attempting to improve the 
state of the practice in verifying and validating ESs, the 
Software Technology Branch has developed a workshop 
to 

• Convince ESs developers that verifying and validating 
their software is important and should be done 

• Teach some basic techniques that help in verifying and 
validating Expert Systems 

• Provide some guidelines that Expert Systems 
developers can follow when applying these verification 
and validation techniques. 

This paper reports the accomplishments of the 
workshop and the future works on verification and 
validation of knowledge-based systems (KBSs). 

Introduction 

Since 1987, V&V of KBS has been one of the major 
tasks of the Software Technology Branch (STB). The 
more significant efforts in this task (through September 
1991) include 

• Building a verification tool 

• Attending the American Association of Artificial 
Intelligence (AAAI) tutorial on V&V of ESs 

• Participating in the workshops on verification, 
validation and testing (VV&T) of KBSs held by the 
AAAI 

• Surveying the state of practice in V&V of ESs 

9 Sponsoring a workshop that gathers all the experts in 
the V&V of the KBSs field so they can come up with 
the standard methodology and guidelines for verifying, 
validating and testing of KBS 
As a direct result of the state of practice in V&V of 
ESs survey, a workshop on V&V of ESs was developed 
to assist developers in doing a better job of building high- 
quality ESs. The focus of the workshop was to encourage 
the application of more systematic V&V approaches to 
ESs development and provide hands-on experience in 
using proven V&V techniques. 


Problem Statement 

The survey used responses (in paper form and from 
interviews) of roughly 60 different ESs projects within 
both IBM and NASA. The survey questioned both 
developers and users of ESs. The goal was to generate 
some hard facts from which to draw conclusions rather 
than relying upon more theoretical speculation. 

The survey sought to answer the following questions: 

• What kinds of V&V techniques are used 

• What kinds of problems are most often encountered 

• To what extent is V&V practiced 

• What is the level of satisfaction regarding ESs quality 

One significant recommendation from the survey was 
that developers needed help in verifying and validating 
their projects. Many of the developers questioned had no 
background in computer science (i.e., they were 
engineers, flight controllers, etc.) and, as a result, had 
limited experience in the systematic application of V&V 
approaches. The ESs V&V workshop described in this 
paper would help developers by teaching the “why” and 
“how” of software V&V. 

Approach/Method 

Purpose 

The ESs V&V workshop addressed two major 
obstacles in the application of V&V techniques to ESs 
projects. The first obstacle concerned lack of experience 
in applying V&V techniques. This affected the 
understanding of how to use the techniques and when to 
apply them. The workshop addressed this obstacle by 

• Increasing awareness about V&V 

• Providing information and hands-on practice for 
specific techniques 

• Providing a set of guidelines for applying V&V 

Another obstacle was that many developers did not 
believe in V&V. The developers felt the additional “up- 
front” costs typically associated with V&V are too high. 
They were convinced that applying V&V can lower 
development cost and have a positive impact on other 
aspects of the system other than just correctness (e.g., 
reduced maintenance costs). 

Workshop Outline 

The ESs V&V workshop was divided into three 
parts: Part 1, basic concepts, reviewed the concepts that 

• Defined V&V 
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• Dispelled some common myths about artificial 
intelligence (AI) and software development 

• Examined the differences between ES and conventional 
software 

• Assessed the impact of these differences on the basic 
concepts of V&V 

Part 2, techniques, examined a wide range of 
techniques developers could use to build more reliable 
systems. Most of these techniques were drawn from the 
study of conventional software development. For each 
technique, the method was described and an example 
shown. During the first part of each class, an example 
problem was discussed. Technique examples were drawn 
from solutions to this example problem. Part 3, 
guidelines, prescribed a complete set of “things to think 
about” when performing V&V on an ESs. 

Basic Concepts 

Part 1 of the ESs V&V workshop encouraged V&V 
for ESs by helping developers understand the underlying 
principles behind V&V. “Correctness” in software was 
examined and discussed within the framework of a 
puzzle. Demonstrating correctness involved examining 
many different facets of a system behind functionality. 
Facets (or pieces) were explored in order to gain a 
complete view of system correctness. 

With a clear understanding of the many types of 
software correctness, focus shifted to the kinds of 
activities that must be performed to demonstrate 
correctness. These activities were called test phases. 
Three test phases were presented: 

• Static testing 

• Unit/integration testing 

• System testing 

Characteristics, inputs, and implications of each 
phase were discussed beginning with system testing. 

After discussing software correctness and test phases, 
focus shifted toward understanding application of these 
concepts to ESs. This shift was where the obstacles in the 
application of V&V to ESs had occurred. These obstacles 
existed, to a great extent, because of many 
misconceptions regarding software in general and Al in 
particular. The workshop addressed many of the most 
common misconceptions that negatively influence 
developers concerning V&V. For example, some 
consider ESs to be fundamentally unreliable due to their 
heuristic nature. Even though reliability may be more 
difficult to prove given the heuristics, the ESs should still 
be 

• Predictable 

• At least as accurate as the heuristic 

• Safe 

Specific techniques were presented to support these 
notions. 

Dispelling some common misconceptions regarding 
software development, the workshop focused on 
differences between ESs and a procedural program. 


Developers learned about the differences in how systems 
are built (implementation differences) and the kinds of 
problems they solve (problem differences). 

At this point, developers understood important V&V 
concepts. TTiey also recognized differences between ESs 
and procedural systems and how those differences 
impacted V&V. This foundation allowed them to begin 
learning techniques, although they still needed to learn 
V&V planning. Survey results indicated the need for 
planning. For example, the fact that so many projects 
were either operational prototypes or did not follow a life- 
cycle model indicated that planning was a problem. If a 
project was poorly planned, then knowledge about V&V 
techniques and the theory behind V&V was of little value. 
For this reason, developers learned the importance 
planning, along with a specific planning approach, play in 
successful V&V. 

Techniques 

Part 1 established the basic building blocks necessary 
to understand and use V&V techniques. Part 2 taught the 
developer 47 different V&V techniques. Some of these 
47 techniques were very specific (i.e., the technique 
implied a specific method), while others were more 
general (i.e., the technique implied a class of errors for 
which many different methods applied). For example, 
path coverage was a very specific technique that implied a 
specific approach and error detection capability. Stress 
testing, on the other hand, pointed to many possible 
methods demonstrating the system worked correctly 
under stress. 

Guidelines 

Part 3 examined implications to V&V resulting from 
key points from the previous parts. Developers learned an 
approach to V&V along with ways they could tailor the 
approach to fit the specific V&V needs of their project. 
Guidelines were high-level suggestions. One reason for 
this approach was that all projects were different. 

Dictating a specific approach with no allowable 
deviations was not only controversial, but extremely 
difficult to carry out. The guidelines provided a step-by- 
step approach addressing the following key activities: 

• Project Management 

• Problem Analysis 

• Requirements Definition 

• Design 

• Technique Selection 

Developers learned to use guidelines to find errors 
early and to perform “smarter” testing by matching the 
right technique to the right situation and system 
representation. 
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Key Points of the ESs V&V Workshop 

The workshop provided a new, positive mindset 
which convinced the students to learn and to use the V&V 
techniques. To sell the need for ESs V&V, the workshop 
focused on several key points: 

• V&V is part of the development process 

• ESs are software 

• ESs are different 

• Find and correct errors as early as possible 

• Requirements are needed for validation 

• Good design helps verification 

Results (What Was Achieved) 

We have found that there is still significant outside 
demand for the workshop and have received many 
positive comments about the value of the material. 
However, it is still too early to detect the long-term 
impact of the class on current V&V practice. Activities 
are underway, however, to begin assessing this impact. 

As with any successful job, however, there is always 
room for improvement. The remainder of this report will 
focus primarily on areas where the workshop can be 
improved. These areas of improvement have been 
derived from informal discussions with the students, 
student evaluations, and instructor observations. 

However, before discussing specific recommendations, 
we feel it is important to discuss the profile of students 
that attended the workshop. Their jobs and perspectives 
on software testing certainly impacted the success of the 
workshop. 

Conclusion and Future Directions 

In summary, a lot of work needs to be done if the 
state of the practice in ESs V&V is to be improved. The 
ESs V&V Workshop is just one small step in that 
direction. Right now, it is still too early to tell what the 
impact on the state of the practice within the NASA 
environment will be. Clearly there have been some 
positive results (many projects leads that attended the 


class indicated they would be applying the workshop 
concepts immediately), however, there is still room for 
more success. 

Based on the instructors’ observations and comments 
from students, future work in improving the state of the 
practice in V&V of ESs will include the following: First, 
we will be identifying specific projects within NASA that 
we can work with directly (as consultants) to apply V&V 
to the project. One drawback to just teaching a workshop 
is that the student alone bears the responsibility for 
applying what they have learned. We feel this leaves too 
much to chance. Working directly with students on their 
project removes this uncertainty and can yield a more 
positive impact . Next, we will be expanding the 
workshop to include other topics that are a little less 
understood but that are starting to get some attention. In 
particular, we will begin to focus on V&V of object- 
oriented systems and V&V of ESs that use techniques 
such as fuzzy logic, probabilistic reasoning, etc. Finally, 
we will modify the workshop to teach an entire 
development methodology (e.g., clean room) and focus on 
learning fewer techniques in greater detail. This should 
help students close the loop on the V&V overview they 
received in the first workshop. 
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Abstract 

The network execution and training simulator 
(NETS) is a software tool that provides an environment 
for the development and evaluation of neural networks. 
NETS was written by the Software Technology Branch at 
JSC. With NETS you can create and execute arbitrary 
configurations of neural networks which use the “back 
propagation” learning technique. NETS is portable and 
will run on a variety of machines from desktop hardware 
to supercomputers. NETS, version 3.0, is currently 
available and is free to NASA and its contractors for use 
on NASA projects. NETS can be obtained by calling the 
Software Technology Branch help desk between the hours 
of 9:00 a.m. and 4:00 p.m. (CST) Monday through Friday 
at (713) 280-2233. NASA contractors should have their 
contract monitor call the help desk to obtain NETS. 

Others may purchase NETS, including all documentation, 
from COSMIC at a nominal fee for unlimited copies with 
no royalties. A brief introduction to neural networks 
along with a description of the history, purpose, 
applications, and features of the NETS software package 
are included. 

Introduction 

The concept of a neural network was originally 
conceived as an attempt to capture aspects of the behavior 
of a biological nervous system with electronic circuits. 
Early work beginning in the 1940s' identified the critical 
concept of the artificial neuron. Establishing such a 
concept essentially amounts to making the crucial 
decisions that determine which of the multitude of 
features of a biological nerve cell will be retained in the 
artificial neuron. 

With the advent of high-speed digital computers in 
the 1960s, the emphasis shifted from electronic 
implementations to computer models. At this time, 
research interest focused on a special neural network 
model known as the single-layer perceptron. 2 Apparently 
researchers of that era failed to note the similarities 
between simple perceptron models and standard fitting 
techniques such as linear regression. These oversights 
were noted by a pioneering researcher in artificial 
intelligence, Marvin Minsky, in his book Perceptrons? 
Minski’s argument showed that a single-layer perceptron 
was theoretically equivalent to a linear separation scheme, 
i.e., could solve only those classification problems for 
which the class boundaries are hyperplanes. A simple and 
now famous example of a problem which cannot be 


solved by a single-layer perceptron is the exclusive or 
XOR problem where the desired output is the exclusive or 
ORE, or the modulo 2 sum of the inputs. Since there 
were well known techniques for determining optimal 
hyperplane separation boundaries, Minski’s book 
relegated neural networks of the time, i.e. the single-layer 
perceptron, to a historical footnote. It was only with the 
rediscovery of the gradient learning rule for multilayer 
perceptrons 4 that interest returned to the field. The NETS 
software is an implementation of the Rummelhart-Werbos 
gradient descent learning algorithm for multilayer 
perceptrons. 

Unlike their single-layer counterparts, a multilayer 
perceptron of the type shown in figure 1 can approximate 
almost any continuous function. It is this task of 
approximation of nonlinear functions or curve fitting that 
is the crucial capability offered by multilayer perceptrons, 
also known as back-propagation neural networks. 

Given the many classical methods for curve fitting 
with well known properties and efficient computer 
implementations, it is natural to wonder why back- 
propagation networks of the type implemented by the 
NETS software are needed. The answer to this question 
lies in the well known limitations of the classical 
methods. Standard statistical methods for function 
estimation require sufficient data to adequately sample the 
domain space of the function which is to be 
approximated. If the domain space is low-dimensional, 
e.g., 1-dimensional, as in the case of a simple plane curve, 
then a sample of the input or domain space sufficient 
enough to ensure an accurate estimate of the distribution 
can easily be taken. Methods such as cubic splines can 
readily provide high-fidelity approximations of a function 
of a single scalar variable given a table of sample values 
for the function which is to be approximated. If, on the 
other hand, the desired function depends on even a 
modest number of parameters — say 10 — it would never 
be possible to provide enough samples to accurately 
estimate the function by means of traditional statistical 
techniques. 

Every known approach to the problem of estimating 
functions of several variables rely on variants of a single 
strategy, namely to represent the function or its input 
space, or both, in a simple form. The feature that 
distinguishes neural networks from other methods is that 
no fixed, simplified representation is assumed. Rather, 
the internal representation is allowed to evolve from the 
data. It is this key adaptive property of the back- 
propagation neural network which provides the capability 
to learn to approximate a function rather than requiring a 
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programmer to anticipate all models needed to perform 
the desired mapping. 

Problem Statement/Description 

The problem that NETS solves can be simply stated 
as follows, Suppose that there is some process which 
produces an output based on an input, and that both the 
input and output of this process can be described 
numerically, i.e., as an input vector 

X = <xi, ... ,x m > and an output vector, 

Y = <yi, ..., y n >, where xj and yi are real numbers. 

As an example, think of the components of the vector 
X as being rainfall totals and spillway flow rates at 
various locations in a river-lake system, and the 
components of the vector Y as being water levels at 
locations of interest. A hydrologist might well be able to 
predict the vector Y corresponding to an input vector X, 
provided that the characteristics of the terrain were known 
and that enough locations were monitored for the input 
vector X to have predictive value for Y. Even so, 
experienced hydrologists faced with this prediction 
problem would most certainly look at historical records, 
at least as a verification of their theoretical estimate of Y. 
Now suppose that we do not have a hydrologist, but do 
have a wealth of historical data for the watershed. We 
could then assemble a table of input/output pairs of the 
form X., Y t where and Y { are samples of input vectors 
X and output vectors Y of the process. The problem is to 
find an approximation Y(X) based on the historical 
examples. If such an approximation could be found, then 
given a new set of data X 0 *" corresponding to an observed 
weather event, a resulting set of river levels Y “ ew could be 
predicted. 

As valuable as such a prediction tool might be in its 
own right, consider the implications of the neural network 
approximation Y(X) that is given in terms of equations 
which are themselves amenable to manipulation by 
numerical methods. In particular, suppose that the portion 
of the X vector corresponding to rainfall totals is known, 
as is an acceptable set of river levels, Y. The equations in 
the approximation Y(X) could then be solved to fill in 
optimal spill rates which would produce the desired 
vector Y. The above scenarios correspond to the 
companion tasks of system identification and control 
which are central to applications of great interest. 

Another important use of neural networks is as 
trainable classifiers. Classification applications are 
usually implemented by passing raw sensor data through 
various transformations designed to suppress variation 
within a given class and enhance class discrimination. 
Such transformations would also normally extract a 
vector X corresponding to an observation of an object. 
This vector, sometimes known as a feature vector, would 
be the input to the neural network. The output Y would 
then be some vector indicating the class corresponding to 


the input X. A standard way of producing such a vector 
for a problem having n possible classes is to set the vector 

Y 55 <yi, y n > 55 o* •••» l> ^ •••» o> 

where the position of the 1 in the Y vector corresponds to 
the class of the object which is observed. 

Applications of the kind described here have driven 
research in neural networks for years, but until recently, 
neural network exploration was impeded by the 
requirement for special hardware and/or software to 
implement the network algorithm. One of the main 
selling points for neural networks over conventional 
solutions was that the same algorithm is applicable to 
many different applications. A need was thus perceived 
to produce a generic package to implement the back- 
propagation neural network algorithm. The requirements 
for the package can be summarized as 

• Portability: The software should run on the widest 
possible range of computer systems. There should be 
no special hardware required, but the code should be 
capable of taking advantage of any commonly available 
resource such as math coprocessors. 

• Simplicity: The software should be easy to install and 
use. It should not be assumed that users will have any 
initial knowledge of neural networks. The code should 
facilitate entry, exploration, and application. 

• Examples: Since most users would be unfamiliar with 
neural networks, the package should include examples 
and tutorial material. 

• Delivery: In order to close out the cycle of research, 
development, and application, it is necessary to support 
the delivery of a trained network module which could 
easily be imbedded in the user’s application. 

The NETS Software 

The network execution and training simulator 
(NETS) is a software tool that provides an environment 
for the development and evaluation of neural networks. 
NETS was written by the Software Technology Branch at 
JSC. With NETS you can create and execute arbitrary 
configurations of neural networks which use the back 
propagation learning technique. NETS is portable and 
will run on a variety of machines from desktop hardware 
to supercomputers. Some of the features of NETS are 

• Learning Method: NETS uses the back propagation 
learning method for all of the networks which it creates. 

• Macintosh Graphical User Interface (GUI): NETS 3.0 
now offers a Macintosh GUI option along with the 
original Command Line Interface (CLI) version. 

• Example Networks: NETS 3.0 comes with three 
sample network specifica-tion files and three I/O files 
containing training data. One of these is the original 
XOR problem. The other two are more advanced 
applications which are accompanied with tutorial 
material in the new user’s guide. There are also 
executable programs for generating virtually unlimited 
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amounts of additional training or test data for the two 
advanced applications. 

• Delivery Capability: Once a network has been 
debugged to your satisfaction, NETS can produce 
portable C source code which implements the network. 
This code can then be incorporated into other software 
systems. 

• Portability: NETS is written in the C programming 
language and can be executed on a variety of machines 
with no code changes. To date, NETS has been 
implemented on a variety of machines including IBM 
personal computers, Apple Macintosh, VAX, Sun, HP 
9000, and CRAY. 

• Scaling Option: NETS 3.0 allows you to scale training 
and/or test data. You may scale inputs, outputs or both. 

• Quick Test Capability: You can now perform a quick 
check of your network's performance on a test set from 
the main menu. 

• Dribble Facility: NETS provides features for saving 
weight values, errors, and test cases of a network to 
files at any time before, during, or after the training of 
the network. This feature is extremely useful for 
debugging network structures. 

• Memory: The memory requirements for NETS are only 
4 bytes per node and 4 bytes per connection. 

• Multiple Formats: NETS contains facilities for 
operating in either floating point or scaled integer 
format. The floating point format provides greater 
accuracy, while the scaled integer format allows for 
greater execution speeds on platforms without floating 
point coprocessors. 

• Multiple Executable Versions: The Macintosh version 
of NETS is distributed with four compiled NETS 
applications — scaled integer (CLI and GUI) and 68020- 
6881 (CLI and GUI). The MS DOS version is 
distributed with executables compiled for floating point 
and scaled integer operation. 

• Source Code: NETS comes complete with all source 
code. 

• Documentation: A full description of the features of 
NETS is provided by the NETS User's Guide. There is 
a supplement describing the new Macintosh GUI. 

• Availability: NETS version 3.0 is currently available 
and is free to NASA and its contractors for use on 
NASA projects. It can be obtained by calling the 
Software Technology Branch help desk between the 
hours of 9:00 a.m. and 4:00 p.m. (CST) Monday 
through Friday at (713) 280-2233. NASA contractors 
should have their contract monitor call the help desk to 
obtain NETS. Others may purchase NETS, including 
all documentation, from COSMIC at a nominal fee for 
unlimited copies with no royalties. An electronic 
bulletin board containing information regarding NETS 
can be reached 24 hours a day at (713) 280-3896 or 
(713) 280-3892. Communications information is 
300, 1200, or 2400 baud, no parity, 8 data bits, and 1 
stop bit. 


Applications 

The NETS software has been extremely popular with 
a total user community numbering over 1,000. NETS is 
in use at all the NASA centers, all branches of the 
military, at many universities and throughout the private 
sector. The most popular applications generally involve 
pattern matching, system identification, and signal 
processing. The following are a few examples of those 
applications which have come to the attention of STB 
through our help line. 

• Pattern Identification - The Army (Rock Island 
Arsenal) is using NETS to examine radiograms of 
munitions to scan for defects. 

• Signal Processing - Research at the Colorado School of 
Mines uses NETS to determine the arrival time of 
special wave forms in seismic data. 

• System Identification - In work at NASA Lewis 
Research Center, NETS is used to predict optimal 
parameters for Space Station design. 

Current and Proposed Research 

The research agenda can be described in terms of two 
prime objectives: 

• to find applications of the new function estimation 
capabilities offered by neural networks 

• to gain an understanding of how neural networks build 
internal representations so that other methods can 
benefit from such a capability 

The best examples of the first objective are the 
research initiatives in neural control. The STB has been 
acknowledged as a leader in this critical area as evidenced 
by the recognition of D. G. Roger's paper, “SPLINES: A 
Hybrid of Friedman’s Multivariate Adaptive Regression 
Splines (MARS) Algorithm with Holland's Genetic 
Algorithm,” as best paper at the Auburn workshop on 
neural networks (February 92). This paper describes the 
implementation of an intelligent adaptive controller which 
learns how to back a two-wheeled trailer along a 
trajectory generated by a simple, rule-based system. The 
integration of the neural network into a rule-based system 
results in a hybrid system displaying the most desirable 
aspects of both methods. The hybrid system, uses 
networks and rule bases which are orders of magnitude 
simpler than those which would be required if the 
problem were to be solved with only a network or with 
only a rule-based controller. 

The second objective is being addressed with 
research such as that being carried out at Ames Research 
Center by R. O. Shelton and J. K. Peterson, and with 
ongoing research in the STB which integrates local linear 
discriminant-based decision trees with back-propagation 
neural networks. Again, the objective is to understand the 
factors which provide the adaptive capability offered by 
the neural network so that other methods can be made to 
learn. 
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NASA Electronic Library System 
NELS 2.0 

Mark E. Rorvig 
John .on Space Center/PT4 


Abstract 

This paper discusses NASA Electronic Library 
System (NELS) 2.0, a general system for enterprise-wide 
information management. The present main features of 
this system are 

• the ability to search, retrieve, print, and copy text, 
image, or sound objects, 

• the provision of a natural language search interface that 
ranks retrieved objects by their relevance to a query, 

• the support for communications between libraries on 
other computer systems through the Wide Area 
Information Server (WAIS) using the Z39.50 Protocol 
for information retrieval, 

9 loads structured data about objects (metadata) and 
source files of full text objects for searching, 

9 a layered architecture for quick replacement of 
graphical user front ends and data base schemas, and 
9 interface links for X Windows, Microsoft Windows, 
ASCII and Macintosh. 

Introduction and Problem Statement 

The general assumption since the mid 1970s is that 
information retrieval (I-R) is about the problem of 
specialists attempting to keep abreast of or review 
specialty literature. Indeed, since the classic studies of 
Project INTREX, this assumption has tended to dominate 
the practice of I-R and has resulted in an ever greater 
number of publicly available data bases in an ever greater 
number of specialties, each in turn awash with its own 
terminology, special features, and idiosyncrasies. The 
counter notion, that I-R might be about the problem of 
nonspecialists, attempting to answer cross-disciplinary, 
multidomain questions is far less frequently considered in 
the construction and use of commercial systems. 

But this state of affairs has not always been the case. 
Indeed, the images of potentiality set forth early in the 
development of I-R presumed a system for general users 
which included documents, sounds, and images in basic 
system design and never assumed that specialist 
assistance would be required for information access. 
Instead, over time, the commercial world focused on 
retrieval methods, in particular retrieval by Boolean 
intersection, that precluded general user access. Of 
interest on this point is a historical note by Cyril 
Cleverdon published in 1987. In his note, Cleverdon 
asserts that Boolean searching of documents became the 
focus of the field by unplanned accident and characterizes 
present systems as “user hostile.” Additionally, these 


systems were constructed on mainframe devices, 
requiring high maintenance costs and high marginal costs 
for system expansion. 

Approach/Method 

One of the primary objectives of the NELS project is 
to allow a user to retrieve personal, corporate, and wide 
area information through one easy-to-use interface. For 
example, instead of using Lotus Magellean™ for personal 
information, Verity Topic™ for corporate data, and Mead 
Data Dialog™ for published text, one application can 
access all three categories of information. The user is not 
required to become familiar with several entirely different 
systems. In addition, since the interface consolidates data 
from many different sources, they can be manipulated 
effortlessly, virtually without regard to their origins. In 
NELS 2.0, therefore, Wide Area Information Server 
(WAIS), as supported by a consortium of companies and 
the National Science Foundation, is used as a replacement 
for Oracle, a costly commercial product. 

The prototype WAIS system as incorporated into 
NELS 2.0 takes advantage of current state-of-the-art 
technology, and presents solutions to all of the above 
problems. The system is composed of three separate 
parts: clients, servers, and the protocol which connects 
them. The client is the user interface; the server does the 
indexing and retrieval of documents; and the protocol is 
used to transmit the queries and responses. The client and 
server are isolated from each other through the protocol. 
Any client capable of translating a user's request into the 
standard protocol can be used in the system. Likewise, 
any server capable of answering a request encoded in the 
protocol can be used. To promote the development of 
both clients and servers, the protocol specification is 
public, as is its initial implementation. 

On the client side, questions are formulated as 
English language questions. The client application then 
translates the query into the WAIS protocol and transmits 
it over a network to a server. The server receives the 
transmission, translates the received packet into its own 
query language, and searches for documents satisfying the 
query. The list of relevant documents are then encoded in 
the protocol and transmitted back to the client. The client 
decodes the response and displays the results. The 
documents can then be retrieved from the server. 

Figure 1 displays these concepts. 

WAIS alone, however, is merely one of the building 
blocks for the total NELS 2.0 system. The complete 
system is composed of two interfaces, a session manager 
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to manage the transfer of information from WAIS to the 
interface, a data manager to provide an SQL access 
protocol to WAIS, WAIS itself, the protocol, Z39.50 for 
communication among servers and networks, and, finally, 
the UNIX operating system resting on physical network 
protocols. Figure 2 displays these system layers. 

Results 

This task will improve the operational capabilities of 
JSC through cost savings in the printing, distribution, 
filing, and storage of paper documents. GM savings 
alone would be approximately $350K annually, which is 
estimated simply by dividing the total number of pages 
(4.5 million) of documents by $25 per 100 printed pages 
($1,125 million) and multiplying that figure by 30%. 
Actual savings might be higher. Assuming that other 
directorates and offices could save only $100K per year, 
cost savings centerwide of $1,000,000 annually are likely. 
These estimates are conservative. 

Additionally, considerable interest has been 
expressed by other NASA and defense agencies in WAIS 
technology. For example, on December 21, 1992, a video 
teleconference of the Space Technology Interdependency 
Group (STIG) was held to investigate the use of WAIS 
technology to provide access to electronic data on space 
technology. STIG participants include NASA centers, 

Air Force, Defense Advanced Research Projects, Defense 
Technical Information Center (DTIC), Jet Propulsion 
Laboratory (JPL), and various contractors. 

The meeting at JSC was attended by Terry Spencer, 
Tamara Bosque and James Whittingdon from the New 
Initiatives Office, Capt. Terrell Scroggins from the 
Armstrong Lab at Brooks AFB in San Antonio, and Dick 
Ramsell, who attended part of the afternoon session. 

Video link attendees included participants from Lewis, 
Ames, Jet Propulsion Laboratory, Marshall, Kennedy 
Space Center, Goddard, and NASA Headquarters. 

Among the D.C. participants were representatives from 
NASA, DTIC, and the Army Space and Technology 
Research Office. The meeting was chaired by Stan Sadin, 
the technical manager of the Office of Advanced 
Concepts and Technology (OACT) at Headquarters. 

The meeting was offered as a proof-of-concept 
demonstration and the objectives listed were to 

* demonstrate WAIS technology 

* spark interest in suppliers and users 
% make the best use of current work 

* develop system users 

At this time, only JSC and Goddard Space Flight 
Center have integrated this technology into information 
management activities. 

Conclusion and Future Directions 


for software reuse. It is the retrieval engine presently in 
use by MountainNet to support the ADANet software 
reuse program. Version 2.0 is a generalized version that 
will eventually replace the ADANet software and will 
also be used to support documentation efforts at JSC and 
other Centers as required. Version 2.0 is structured into 
three layers: GUI/AUI, a session manager, and a retrieval 
engine. The retrieval engine used in this version will be 
WAIS. The session manager will modify WAIS 
references to permit extensive browsing of collections. 
Internal field and element structures will conform to those 
of NASA’s Center for Aerospace Information. Internal 
data representations will conform to Library of Congress 
MARC specifications. 

Future plans emphasize the development of graphic 
objects, surface mapped to selections of drawings, 
documents, images, and voice recordings. 
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Figure 1. NASA Electronic Library System (NELS 2.0) WAIS Overview. 
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Optical and Photo Equipment Bracket for the Shuttle Starboard Overhead Window 


Thomas Rathjen 
Johnson Space Center/SP43 


Abstract 

Observing payloads, the Earth, and celestial objects 
through the windows of the Shuttle is an important part of 
every mission. Occasionally, steady and precise 
positioning of optical or photographic equipment is 
required. Therefore, Flight Crew Support Division 
(FCSD) developed a system which secures a variety of 
hardware to the structure at the Shuttle's starboard 
overhead window and that provides both coarse and fine 
two-axis pointing. 

Introduction 

In the past, equipment that needed to be secured at 
the overhead windows was clamped into existing 
provisions normally used for window shades. These 
clamps were not designed for this application and NASA 
became concerned that continuing to do this could 
damage the window glass. Therefore, Rockwell 
International was tasked to add interface provisions 
specifically designed for supporting observation hardware 
to the Shuttle fleet. However, hardware to attach optical 
and photographic equipment to these interface points was 
left for NASA to provide. 

In the fall of 1991, Flight Crew Support Division was 
approached by the crew for STS-46. They planned to 
view the Tethered Satellite System (TSS) with a Celestron 
telescope as it was deployed 12.5 miles from the Shuttle; 
however, they needed hardware to mount the telescope in 
the window. In order that the device could be used for 
other applications on additional Shuttle missions, it had to 
be designed to accommodate several different telescopic 
lenses as well as the telescope. 

Problem Statement 

The hardware not only had to rigidly mount the 
telescope at the overhead window, it also needed to 
provide two-axis adjustment so the crew could track the 
TSS as the Orbiter “dead banded” (as the Shuttle 
orientation varied by +/- 5 deg about the x and y axes). 
Since viewing the TSS was the first application to require 
attaching hardware to the new Shuttle interfaces, a unique 
design was required. Funds for developing the hardware 
were limited, and designing a custom pointing system 
could be expensive. Therefore, a means of meeting the 
requirements at minimal costs had to be found. The 
hardware also had to be stowed for launch and landing. 

The new interface points consisted of two threaded 
fasteners and two holes for pins. This design 


accommodates dimensional tolerance differences between 
Shuttles; however, it presented problems in securing a 
bracket to these points rigidly. An undersized pin could 
potentially rattle in the holes, ruining observations. 

A survey of the various telescope lenses optionally 
flown on Shuttle missions revealed a wide variety of sizes 
and mounting footprints. Accommodating the different 
lens lengths, while still allowing all lenses to be 
positioned close to the window surface, could not be 
accomplished with a single piece, static bracket. 
Furthermore, none of the equipment included positioning 
holes which could be used to firmly secure them to the 
bracket. Therefore, a clamping mechanism that could be 
used with all mounting footprints had to be designed. 

Isolating the observation equipment from cabin light 
was also important. Fabric shrouds, which tie around 
lenses, are available for Shuttle missions, but they would 
not accommodate the large diameter telescope. 

Therefore, a new shroud had to be designed. Because the 
shroud would likely be the last thing installed during 
equipment setup, it had to be possible to install and 
remove it without disconnecting the interface 
attachments. 

Approach 

The FCSD’s resulting hardware consisted of two 
major components: an interface frame and an adjustable 
bracket. The frame, which includes the light shroud, 
rigidly connects to the new Shuttle attach points. It is 
stowed in the Shuttle window shade bag for launch and 
landing. The bracket, which includes the pan and tilt 
features, is locker stowed for launch and landing. The 
bracket is easily attached to the frame via three captive 
thumb screws (fig. 1). 

To provide fine, two axis adjustment, an off-the-shelf 
pan-and-tilt head was identified. If used as is, there 
would have been too much slop for the STS-46 
application. It was easily modified, however, by 
machining parts to tighter tolerances. Although it 
provided more than the required +/- five degree range for 
the dead banding, it did not adjust enough to account for 
all planned positions of the TSS relative to the Orbiter. 
Therefore, coarse adjustment about the y-axis up to 
+/- 90 degrees was built into the bracket. 

To eliminate the potential rattling of the pins in the 
loose interface holes, O-rings were added to the base of 
the interface pins. Upon installation in the window, as the 
pins are pushed into the holes, the O-rings are compressed 
between the interface frame and the Shuttle structure, 
ensuring a tight fit. 
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A coarse adjustment in the z-axis was added to allow 
for an adjustment to account for short and long lenses. 
Because of the significant length differences and the size 
limit on the bracket due to stowage requirements, two 
attach points for lenses were included. Figure 2 shows 
the resulting minimum and maximum lengths for the lens 
attach points to the window. 

Clamping the telescope and lenses tightly to the 
bracket became a challenging design problem. Because 
none of the lenses included positioning holes, sliding 
clamps were designed that provide torsional support. 
These clamps slide against the sides of the mounting 
bases on the lenses, preventing them from rotating. High- 
friction surfaces between the clamps and the bracket 
prevent them from being forced aside if a rotational load 
were applied to a lens. 

To solve the problem of providing a shroud that 
completely blocks cabin light, yet can be installed and 
removed without removing the interface frame, black 
Nomex fabric material with strategically placed stiffeners 
was used. While most of the shroud is flexible, the 
forward and aft end shade provisions, which are clamped 
in the Shuttle window, included aluminum bars. The 
inboard and outboard sides include Armelon stiffeners to 
provide some rigidity so the shroud will not float in front 
of the lenses or telescope. The open end of the shroud 
includes a Velcro pattern which matches the existing 
shrouds. 

Results 

The overhead window bracket system was used 
successfully on STS-46 during TSS activities. Since the 


TSS could not be deployed to the desired 12.5 miles from 
the Shuttle, the telescope was not used for observation as 
planned. However, the crew did set the system up and 
verified that it performed as required. Figure 3 shows 
astronaut Jeff Hoffman installing the Celestron telescope 
in the bracket on STS-46. Two flight units were 
fabricated and will be available for future flights as the 
need arises. 

Conclusions 

The Flight Crew Support Division met the STS-46 
crew’s needs with the overhead window bracket system, 
and the design is versatile enough to support future 
missions as needs are defined. The experience on STS-46 
confirmed that it does provide steady and precise 
positioning of optical or photographic equipment while 
secured to the new Shuttle interfaces. The next planned 
flight of the overhead window bracket system is STS-51. 
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Figure 3. Overhead Window Bracket System Being Set Up on STS-46. 
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Shuttle Orbiter Repackaged Galley (SORG) 


Thomas Rathjen 
Johnson Space Center/SP43 


Abstract 

The new Shuttle Orbiter repackaged galley (SORG) 
developed by the Flight Crew Support Division (FCSD) at 
JSC began flying on all Space Transportation System 
(STS) missions in 1992. Although the weight and volume 
of the SORG were substantially reduced with respect to 
its predecessor, it provides the same food preparation 
capabilities for Shuttle crews. Several design deficiencies 
were also eliminated with the SORG, and the 
maintainability was improved. 

Introduction 

In late 1986, the backlog of experiments resulting 
from the STS-51L accident prompted plans to add 
additional payload carrying provisions to the Shuttle 
middeck. Because the existing galley utilized middeck 
volume inefficiently, and future Extended Duration 
Orbiter (EDO) missions would require optimized use of 
crew compartment space, it was a prime candidate to be 
replaced by these new payload provisions. The alternate 
food preparation hardware available required locker 
stowage volume and more crew time for meal 
preparation. Therefore, JSC’s Space and Life Sciences 
Directorate and the Astronaut Office recommended 
developing a new, smaller galley which could be located 
in previously unused areas of the crew compartment. The 
resulting SORG Program was approved by the Shuttle 
Program Office in January 1989 as an in-house JSC 
project to be managed by the Flight Crew Support 
Division. 

In addition to producing a smaller galley without 
sacrificing food preparation capabilities, several other 
goals became part of the SORG Program. In-fight 
anomalies and ground-test failures identified several 
design deficiencies with the existing galley. Solving 
these problems and improving the maintainability were 
important. Despite the problems, however, NASA had 
gained significant experience with the old galley and its 
interfaces with the food system and crew. Therefore, the 
SORG was to utilize existing components and designs 
where practical. 

Description 

The SORG had to provide a method to dispense both 
hot and cold water into all rehydratable food and beverage 
packages. An oven for heating rehydrated and shelf- 
stable foods was also required, and it had to accommodate 


up to seven meals at a time. The Shuttle provides ambient 
and cold water only for the galley, so the SORG had to 
heat water and store it in a tank maintained at a 
temperature sufficient to provide hot dispenses on 
demand. 

One of the more troublesome problems with the old 
galley was the inaccuracy of the dispensed water 
quantities. During several of the missions after return to 
flight, crews reported significant overdispenses. 

Although they could compensate for this by selecting 
lower quantities, it was difficult to predict the amount of 
overdispense. During later missions, several crews 
reported erratic and unpredictable dispensing. 

Eliminating this problem was a SORG Program priority. 

The SORG design also had to solve the two 
electromagnetic interference (EMI) problems of the old 
galley. Radiated EMI did not meet Shuttle requirements, 
and a waiver was required for all flights of the old galley. 
Self-induced EMI transients also caused functional 
problems with the galley itself: operating the oven fans in 
certain modes could cause unwanted dispenses, and the 
cycling of the pumps and valves occasionally caused 
microprocessor lockup. Both situations required special 
crew procedures as workarounds. 

Finally, a potential hazard with the hot water tank 
was left for the SORG Program to solve. Nominally, the 
galley or SORG is connected to the Shuttle’s water 
system, which can accommodate the thermal expansion 
when water is heated. However, if a valve or quick 
disconnect failed closed, isolating the galley from the 
Shuttle’s water system, then thermal expansion could 
have caused the galley tank to rupture. Again, this 
required special crew procedures to avoid the hazard, and 
the SORG Program had to eliminate it. 

Approach 

Several potential locations for the SORG in the 
middeck were identified and evaluated, and the area just 
forward of the old galley location (forward, port corner of 
the middeck) was chosen. Based on the volume available 
in that area, the functional requirements, and the desire to 
preserve experience with food and crew interfaces, the 
following parts were identified to be reused: the hot 
water tank, water heater coil, rehydration station, and 
electronic control box. All these components would 
require extensive modifications, however, to eliminate the 
problems discussed above. 

All hardware requiring easy access during meal 
preparation (oven, rehydration station, controls, etc.) were 
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located in the main SORG package, just aft of the lockers 
on the port wall. The hot water tank was located just 
forward of that, in the previously unused volume between 
the lockers and the port wall (fig. 1). The weight and 
envelope of this packaging was calculated early in the 
Program based on preliminary designs. That information 
was communicated to Rockwell International, who could 
then make the necessary structural changes to the Shuttle 
fleet. 

The FCSD discovered the primary reason for the 
dispense quantity problems for the old galley was 
differences between the actual water system of the Shuttle 
and the ground support equipment (GSE) water system 
used to calibrate the dispense times for the old galley. 
Dispense quantities were controlled by these times, 
assuming constant pressures. Although the static water 
pressure could be simulated by the GSE, the pressure drop 
during water flow was much greater than in the Shuttle. 
This resulted in longer dispense times than needed and 
overdispenses in flight. To resolve this, the GSE was 
changed so that it more closely approximated the Shuttle. 
However, because modifications to the Shuttle could 
change the performance of the water system, some of the 
adjustment capability was added to the SORG; pressure- 
compensating flow regulators were designed and 
fabricated in house at JSC and added to the SORG's 
ambient and cold water inlet lines (fig. 1). The pressure 
compensating feature helps keep quantities constant as the 
Shuttle’s water pressure varies between 15.5 and 
20 PSIG. 

The erratic dispense quantities of the old galley were 
related to the EMI problems, as were the microprocessor 
lockups. To eliminate all EMI-related problems, the 
sources of the EMI noise were identified to be primarily 
the pumps and the microprocessor. These components 
were then completely enclosed in EMI sealed containers, 
and EMI filtered connectors were used. EMI sealed 
backshells were then used on all interconnecting cables 
inside and outside the SORG. 

The improved electrical packaging also resulted in 
improved maintainability for the SORG. Because all 
electrical subassemblies are interconnected via cables and 
connectors, they can be removed and replaced without 
cutting wires or soldering. Many components can be 
removed and replaced without removing the SORG from 
the Shuttle. 

To eliminate the potential hazard from the thermal 
expansion of water in the tank, a spring-loaded expansion 
cylinder was developed. An off-the-shelf accumulator 
could not be used because of the requirement to have no 
dead spaces in the potable water system where 
microorganisms could develop. The head of the piston in 
the cylinder has a machined groove through which water 


flows during each hot water dispense. The piston remains 
at the top of the cylinder unless thermal expansion 
actually causes an over-pressure condition. In such a 
case, the piston would then move against a spring, 
opening a volume large enough to accommodate thermal 
expansion of the entire SORG hot water loop. 

Results 

The final SORG design occupies about half the 
volume of and weighs about 45 lb less than the old galley. 
EMI certification testing verified that EMI levels are 
within requirements, and none of the EMI-related erratic 
behavior of the old galley could be duplicated on the 
SORG. All food preparation capabilities were 
maintained, and by reusing key components from the old 
galley, crew training has been kept to a minimum. 

To date, three flight SORG systems have been 
delivered and have flown on five Shuttle missions, 
including the longest mission ever, with no major in-flight 
problems. Samples taken on STS-50, as well as 
qualitative crew comments, indicate dispense quantities 
are within the allowed tolerance of +/- 10%. Crews have 
also commented favorably on the performance of the hot 
water tank and oven and on the performance of the water 
recirculation, which assures that the cold dispenses are 
cold and the hot dispenses are hot immediately on 
demand. 

Conclusions 

The FCSD must still provide a SORG for the Space 
Shuttle Atlantis in late 1993, as well as two spare flight 
units and a fourth trainer. Crew comments and the 
SORG’s in-flight performance will continue to be 
monitored, and design improvements will be 
recommended and implemented if required. 
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Figure 1. SORG Installed On Shuttle Middeck (Lockers Removed). 
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Figure 2. Cross Section of In-House-Designed Pressure-Compensating Flow Regulator 
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Abstract 

The Graphics Analysis Facility (GRAF) has been 
used frequently to study extravehicular activity (EVA) 
maintenance scenarios on Space Station Freedom. The 
ability to use 3-dimensional visualization gives a more 
accurate estimate of the Space Station environment. 
Moreover, human EVA and robotic kinematics can be 
accurately simulated for volumetric reach and collision 
detection analysis. An animation was developed to study 
and discover problem areas involved with doing external 
Space Station maintenance tasks. It was discovered that 
items such as handholds and temporary restraint 
mechanisms should more effectively facilitate EVA 
movement about the Space Station structure for the suited 
personnel. Issues concerning the crew and equipment 
translation aid (CETA) cart configuration, portable work 
platform (PWP) stowage location, and locations of the 
EVA stowage of equipment and tools (ESE&T) boxes 
were also identified by use of the animation. There is also 
a strong desire to make EVA and robotics interfaces 
compatible on items such as replacement units and 
unpressurized logistics carriers. Graphics animation 
provides a mechanism to simultaneously analyze several 
mission parameters, and this has proved to be an effective 
method for mission evaluation. 

Introduction 

This animation was developed at the request of JSC 
personnel to provide an end-to-end scenario of Space 
Station EVA maintenance tasks. The mission timeline, 
along with the design for much of the EVA support 
equipment, was developed by McDonnell Douglas Work 
Package 2 (WP-2). The on-orbit retrievable units (ORUs) 
chosen for replacement were believed to represent worst 
cases for EVA worksite tasks and thus would identify the 
most issues. 

Problem Statement 

Maintenance tasks on the Space Station can be very 
complex because they involve several different worksites 
and the integration of numerous pieces of equipment. 

With this complexity, it is difficult to pinpoint the 
problems in the mission procedures or those in the 
hardware designs. Animating the maintenance 
procedures from end to end gives a visual of what is 
happening in the timeline and of how well all the 
components of the Space Station work together. In this 


way, developing an animation for a complex task can aid 
in bringing out the problems in a task timeline and the 
inadequacies of hardware design. 

Approach 

The first step of the analysis involved refining the 
mission timeline to an acceptable level of detail that 
would best identify the issues of EVA maintenance 
without bogging down the animation with procedures 
common to all EVA tasks, primarily tethering and 
untethering. 

Before the animation could be generated, many of the 
models had to be updated to the latest design to give an 
acceptable representation of the Space Station 
environment. Most of the EVA hardware and support 
equipment designs were new and had to be completely 
modeled. With the mission timeline and the Space 
Station models all updated, the animation could then be 
generated. 

Results 

The issues identified in this analysis were based both 
on the development phase of the animation and on the 
results of the end product. 

It was found that many of the EVA support structures 
such as handholds and temporary restraint mechanisms 
were not effective in facilitating the EVA personnel about 
the Space Station structure. Many of the handholds were 
too far apart, and in some cases there were no handholds 
in the crewmember’s vicinity. 

The CETA cart configuration did not allow easy 
movement about the cart, and the top of it could not be 
reached while the crewmember was in the adjustable 
portable foot restraint (APFR). Handholds were added to 
the cart to facilitate the crewmember’s tasks (fig. 1). 

The stowage locations for the unpressurized logistics 
carrier (ULC), PWP, and ESE&T were not easily 
accessible, which caused very lengthy and sometimes 
difficult translations on the part of the EVA crewmember 
(fig. 2). The amount of time for worksite setup was 
nearly 50% of the total time of the animation, and much 
of that was spent acquiring EVA equipment from stowage 
and spare ORUs from the ULC. 

In the area of EVA versus robotics, many of the 
worksite setup tasks such as acquiring the PWP from the 
mobile based servicer (MBS) could probably have been 
done via robotics before the EVA crew egressed from the 
airlock (fig. 3). This would make better use of the crew’s 
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time on EVA by giving them more time to perform the 
tasks that can only be accomplished by a human. 

Conclusions 

In this analysis, several important issues were 
brought out. All of these issues had a negative effect on 
the efficiency with which an EVA crewmember can 
perform maintenance tasks. Many of the problems which 
involved EVA equipment design are now being targeted 
by various Space Station groups at JSC. 

The CETA handrail and other handholds are being 
evaluated for EVA reach, and new requirements are being 
set to assure that all handholds are properly placed for 
EVA reach and safety. 

The CETA cart configuration is now undergoing 
changes, and the GRAF lab is directly involved in this 
analysis. Several different configurations have been 
analyzed to see which design best integrates the EVA 
crewmember with the EVA equipment on board the 
CETA cart. 


The GRAF lab is currently analyzing different 
locations and configurations for placement of the ULC 
during EVA maintenance missions. This analysis has the 
ULC placed on the MBS rather than at the port end of the 
Space Station structure. 

Graphics animation provides a mechanism to analyze 
several mission parameters simultaneously (i.e., EVA 
reach, volumetric analysis, and task procedures and 
timelines) and thus has proven to be an effective method 
for mission evaluation. By utilizing this type of lab, 
designers and integrators can find hardware design 
problems as well as problems in the configuration of 
complex pieces of equipment. 
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Figure 1. CETA Cart Configuration. 
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Abstract 

Tumor cells are characterized by abnormally high 
amounts of DNA within the nucleus, rapid proliferation, 
loss of attachment dependence and the lack of contact 
inhibition which is manifested as uncontrolled growth. At 
some point in the development of many cancers, certain 
tumor cells (metastatic cells) are directed to leave the 
primary tumor, invading adjacent tissues and migrating to 
a new metastatic site. These metastatic cells secrete 
proteolytic enzymes as a mechanism to dissolve the 
extracellular matrix between cells, enabling the tumor cell 
to migrate through normal tissues. Urokinase (uPA) is a 
key enzyme related to metastasis in cancers of the lung, 
colon, gastric, uterine, breast, brain, and malignant 
melanoma. Currently, urokinase is extracted from the 
tumor biopsies and measured as the ng/mg of total 
protein. The Johnson Space Center has developed 
microassays for urokinase produced by human cells in 
support of spaceflight experiments, including monoclonal 
antibodies that are specific for both active and inactive 
forms of the enzyme. This NASA technology has been 
combined with other cytological testing of tumor cells to 
identify aggressive tumor cells that are actively 
metastasizing. This technology utilization project has 
combined fluorescence microscopy, image analysis, and 
flow cytometry, using fluorescent dyes and urokinase- 
specific antibodies to measure uPA and abnormal DNA 
levels inside the cancer cells. Cytopathology and image 
analysis has shown that uPA is present in high levels in 
many breast cancer cells but not found in a normal breast. 
Significant amounts of uPA also have been measured in 
glioma cell lines cultured from human brain tumors. 
Comparisons of flow cytometry (FCM) and digital image 
cytometry (ICM) of fluorescent-labeled tumor cells have 
shown that ICM can provide measurements that have less 
variation than FCM and can measure uPA concentrations 
on the surface of the cells. Combining FCM and ICM has 
resulted in new analytical procedures that are suitable for 
rapid screening and more precise analytical measurements 
of cells that contain high levels of DNA and uPA. 
Commercial applications include new diagnostic tests for 
metastatic cells in different cancers, which are being 
developed with a company that provides a medical testing 
service which uses flow cytometry for DNA analysis and 
measurement of hormone receptors on tumor cells from 


patient biopsies. If a significant number of tumor cells 
contains large amounts of uPA (especially membrane- 
bound), then the post-surgical chemotherapy or 
radiotherapy can be targeted for metastatic cells that have 
already left the primary tumor. A retrospective study of 
biopsy tissues from 500 node negative, stage I breast 
cancer patients is under way. This research also may 
provide the basis for developing a new therapeutic 
treatment against metastasis using chemotherapeutic 
drugs or radioisotopes conjugated to urokinase-specific 
monoclonal antibodies that only bind to metastatic cells. 

Introduction 

Malignant cells are characterized by abnormal levels 
of DNA, rapid proliferation, uncontrolled growth, and the 
ability to invade surrounding normal tissues. The 
measurement of biochemical markers on cancer cells can 
provide quantitative information about disease-free 
survival and time to relapse, thus providing the physician 
with valuable data for planning adjuvant therapy. Indirect 
immunoassays of markers extracted from biopsy tissues 
are important, but more precise measurements can be 
made by analytical cytometry. The current trend is 
toward microscopic analysis of the immunochemically 
stained tumor sections or dissociated cells, coupled with 
quantitation by image analysis. Specific markers can be 
directly associated with the cancer cells, as opposed to 
biochemical extraction procedures. Tumor markers 
currently assessed include those that measure cellular 
proliferation, the presence of specific onco-genes, tumor- 
suppressor molecules, and cancer-related proteins. 15 

The tumor-related proteins include marker proteins 
(p53, Ki 67, etc.) that are over-expressed in tumor cells 
and proteolytic enzymes that are correlated with recurrent 
disease and metastasis. These enzymes are involved in a 
cascade of proteolytic interactions with other enzymes 
and inhibitors that allow the cancer cells to dissolve the 
surrounding extracellular matrix, thereby enabling the 
cells to invade adjacent tissues rapidly and migrate to 
metastatic sites quite distant from the primary tumor. 
Among these proteases are the plasminogen activators 
(PA), collagenase IV, laminase, and in some cases 
cathepsin D, which together mediate key steps in invasion 
process of metastasis. 
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Measurement of Abnormal Tumor Cell 
Proliferation 

The DNA content in normal cells is a precise amount 
depending on the phases of the cell cycle. DNA can be 
measured by labeling with DNA-specific fluorescent dyes 
or DNA precursors (BrdU, IdU). Then, fluorescent- 
labeled antibodies, specific for the DNA precursor, can be 
used to identify and localize which cells are synthesizing 
DNA. 1 Fluorescent labeled cells then can be analyzed in 
a laser flow cytometer or fluorescent microscope. A 
histogram of DNA content in normal cells shows a single 
diploid peak (at G x phase) and a tetraploid peak (at G 2 +M 
phase). However, in most biopsies the abnormal DNA 
content of tumor cells is detected as a second G t peak or 
multiple peaks. Abnormal DNA (DNA aneuploidy) is 
considered an independent indicator of tumor 
aggressiveness and poor prognosis that is used to 
supplement cytopathology grading of the tumor. 

Flow cytometric measurement of the percentage of 
proliferating tumor cells that are involved in synthesizing 
DNA (S-phase cells) is also an independent indicator of 
malignancy. High percentages (15 -20%) of S-phase 
tumor cells usually indicate an aggressive malignancy and 
usually correlate well with abnormally high DNA content. 
The labeling index (LI) obtained by pulse-labeling cells 
with DNA precursors represents the rate at which DNA is 
being synthesized in tumor cells. Usually, a LI > 4% is 
associated with a higher probability of recurrent 
malignancy. 2 Antibodies against PCNA have been used 
as a measure of tumor cell proliferation. 3 In tumors, high 
levels of PCNA usually are expressed in all cell phases of 
the proliferating cells. Pulse labeling with BrdU is used 
to labels cells specifically in S phase. 4 

Enzymatic Mechanisms of Metastasis 

Cancer cells must secrete proteolytic enzymes to 
dissolve the basement membranes and intracellular matrix 
between the densely packed normal cells to leave the 
primary tumor and migrate to a new metastatic site via the 
blood or lymphatic circulatory systems. Proteolytic 
enzymes such as cathepsin D, collagenase IV, and 
plasminogen activator enzymes have been linked with the 
invasion of tumor cells into adjacent normal tissues and 
with metastasis. Urokinase is not produced in most 
normal cells except for low levels in certain types of 
normal kidney cells, colon, gastric mucosa, macrophages, 
and endothelial cells lining small arteries. However, high 
levels of urokinase is produced in many tumors such as 
breast, 4,9 lung, 10 colon, 11 gastric mucosa, 12 uterine, 13 
bladder, 14 prostate, 15 and malignant melanoma. 16 

High levels of urokinase (>3.49 ng/mg of total 
protein) extracted from breast tumor tissues have recently 
been shown to be a good prognostic indicator for high risk 
of recurrence and shorter patient survival times. 17 
Primary lung and colon tumor cells also produce more 
uPA than metastatic cells, but different extraction assays 


often give widely variable results. 13 Total uPA measured 
from tumor tissue or secreted by cultured explants is 
difficult to quantitate, especially if the measurements are 
made on a large group of cells. The data obtained are an 
average value of all normal and cancer cells rather than a 
measurement of each individual cell. Few direct 
measurements of intracellular and extracellular urokinase 
have been made. 10 * 18 Urokinase (uPA) can be present in 
the tissues in several molecular forms. The inactive 
proenzyme is a single-chain protein (scuPA) that is 
cleaved at Lys.158 to form the double chain, high 
molecular weight active form (HMW-uPA) that is 
54 kDaltons. A low molecular weight form( LMW-uPA) 
can also be formed by cleavage of the HMW-uPA at 
Lys.135 - Lys.136 giving a 35 kD active enzyme. The 
active urokinase enzyme converts plasminogen into 
plasmin, which in turn dissolves intracellular fibrin matrix 
components as well as activates collagenases, laminases, 
and other related protease enzymes which are important to 
the anchorage and growth regulation of cells (fig. 1). 
Recently, it has been shown that the HMW active form of 
urokinase, bound to the tumor cell membrane, is 
responsible for the local lysis of the extracellular matrix, 
hence the tissue invasion mechanism for metastasis. 10 
Receptor (membrane) bound uPA is twice as efficient 
(catalytically) as free fluid-phase uPA. 19 The unbound 
uPA and the LMW form is not responsible for most of the 
local dissolution of extracellular matrix in the immediate 
vicinity of the metastatic tumor cell. The presence of 
plasminogen activator inhibitors (PAI-1, PAI-2) also is 
correlated with a better prognosis and is inversely related 
to high levels of uPA (poor prognosis). PAI-1 binds to 
the active HMW-uPA, but not to the inactive scuPA. 20 
Also, after PAI-1 binds to the membrane-bound active 
uPA, the complex is internalized into the cell and 
degraded. 21 

The complexity of the many interrelationships within 
the cascade of proteolytic activations makes it difficult to 
use an average value for the level of uPA produced by all 
of the cells in the tumor, especially since most of the 
normal cells do not produce uPA, nor do many of the 
tumor cells unless they are actively metastasizing. The 
challenge is to quantitatively measure uPA inside and on 
the surface of the cancer cells and then correlate those 
uPA levels with other specific markers to characterize the 
metastatic scenario for each tissue type and stage of 
cancer. No previous method has been developed to 
accurately measure the intracellular urokinase content, 
membrane-bound urokinase and cellular secretion levels 
and then correlate those urokinase levels with DNA 
content, DNA synthesis, hormone receptors, and other 
markers of aggressive tumor growth to determine the 
metastatic potential. Figure 2 illustrates the difference 
between the current assays for extracted urokinase and the 
new NASA method for precise measurements of 
urokinase contained within the cell or bound to the cell 
surface. This project has developed a quantitative 
diagnostic test for urokinase to be used first with existing 
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panels of cytological evaluations of breast cancer and 
brain tumors cells. Later, it will be applied to other types 
of cancer. 

Quantitative Analysis of Individual Cells 

Correlations of uPA with other markers require more 
precise knowledge about uPA and the multiple 
biochemical interactions that affect its proteolytic action. 
Figure 2 illustrates the current methods of measuring 
average levels from all tumor cells versus our method for 
measuring uPA directly in the cells. Our technology 
utilization project has used flow cytometry and image 
analysis of fluorescent microscopic images to measure 
urokinase and DNA in histopathology tissue sections of 
breast tumors, in dissociated cells (prepared in single cell 
suspensions) taken from tumor biopsies, and in several 
cell lines of malignant brain tumors (gliomas). Fresh cells 
are isolated from tumor tissue or cytological samples and 
prepared for antibody incubation in the same manner. 
Histology sections are prepared from frozen tissues or 
deparaffinized sections cut from previously embedded 
biopsies. The antibodies specific for urokinase are 
incubated with the cells or tissues first, then the cells are 
incubated with a second antibody having a fluorescent 
marker detectable by analytical cytometry techniques. 
DNA content and synthesis rate (based on DNA stains or 
uptake of DNA precursors) is measured by flow 
cytometry or image analysis. The same cell sample can 
be measured for DNA content and urokinase by staining 
of the DNA and labeling the urokinase with a fluorescent 
marker that emits at a wavelength different from that of 
the DNA dye or marker. Thus, both the DNA and 
urokinase can be measured simultaneously, using two- 
color image analysis or flow cytometry. Image analysis 
can localize and quantitate uPA in the cytoplasm and cell 
membrane. An advantage of the use of cell lines is the 
ability to study uPA expression in relation to cell 
proliferation and DNA replication. We also are 
conducting a retrospective study on biopsies from 500 
Stage I, node negative, breast cancer patients in 
collaboration with the Ontario Oncology Working Group 
made up of researchers from three Canadian and three 
U.S. cancer centers. 

Methods 

The expression of uPA was studied during 
exponential growth, as well as in cultures that were placed 
on serum-free medium. Quantitation of uPA levels 
involves immunofiuorescent staining with anti-uPA 
monoclonal antibody (#394, obtained from American 
Diagnostica, Greenwich, Connecticut) as the primary 
antibody using the indirect technique. The second 
antibody consisted of fluorescein-conjugated goat 
antimouse IgG for flow and image cytometry studies or, 
in some cases, rhodamine-labeled goat antimouse IgG for 
image cytometry. DNA labeling was performed using 


propidium iodide or antibodies against 
bromodeoxyuridine following incorporation into DNA. 

Digital image analysis was conducted using both 
Nikon and Zeiss fluorescence microscopes equipped with 
a high resolution video camera connected to a 
QuickCapture board (Data Translation, Inc.) for the 
Macintosh II Fx. The fluorescent filters in the Zeiss 
microscope were matched closely with the bandpass 
filters of the EPICS flow cytometer so image cytometry 
and flow cytometry data on cells from the same sample 
could be compared. Images were stored as TIFF files and 
later analyzed using NIH Image Version 1.4. Individual 
cells were scanned for mean optical densities and 
normalized for area. Relative fluorescence was compared 
after subtracting any background or autofluorescence 
measured from control cells on the same slide. Areas of 
concentrated uPA, within the cell and bound to the cell 
membrane, were further analyzed by density slicing and 
thresholding followed by particulate analysis of those 
specific areas. 

Analysis of fluorescence by FCM was conducted 
with the 488 nm line of an argon laser of a EPICS Profile 
flow cytometer (Coulter Corporation, Hialeah, Florida). 
Green light from fluorescein emission was passed through 
a narrow bandpass interference filter (520 +/- lOnm), 
while red light from PI or rhodamine was passed through 
a 630 long pass filter. Bivariate, 64 x 64 channel 
histograms were obtained for analysis of mean 
fluorescence intensity. Data also were normalized for area 
and fluorescence intensity after the background was 
subtracted. This allowed comparisons among cells from 
the same samples and comparisons between cell lines and 
different samples. Statistical analysis of the data was 
performed by multivariate analysis using Statview 512 
(Abacus Concepts, Inc.) 

Results 

Image Analysis of uPA 

Each cell can be scanned to obtain optical density 
levels that can be compared among cells after 
normalizing with area of each cell measured. It is 
possible to measure the membrane-bound uPA by 
differential analysis using the mean density level of the 
weaker cytoplasm subtracted from that of the whole cell 
containing the membrane-bound enzyme. The zone size 
is defined as a number of pixels to be counted; then the 
relative amount of uPA in that particular density slice of 
fluorescence can be measured automatically by particle 
analysis. This data is expressed as the number of 
particles, average particles per group, area, perimeter of 
the cells, and location of particle groups larger than a 
defined size. The particle analysis method is efficient for 
the quantitative measure of membrane-bound uPA. 
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Brain tumors 

Glioma cells that have been labeled with rhodamine- 
conjugated antibodies for uPA are shown in figures 
3a and 3b. These tumor cells (CS line) contain large 
amounts of urokinase per cell, and there is considerable 
variation in total uPA from cell to cell. It is clear that the 
uPA concentration also is quite varied throughout the 
cytoplasm. Some cells exhibit “hot spots” of 
concentrated uPA, especially on the membrane. Specific 
areas of uPA can be measured by selecting a density 
slice(s) that represents the major portion of concentrated 
uPA (rig. 4) and conducting particle analysis using the 
density threshold that corresponds with the concentrated 
zones of uPA. 

Breast Tumors 

Evaluations of anti-uP A-labeled breast cancer 
sections reveal that normal breast tissue does not contain 
uPA except for some endothelial cells lining the 
arterioles. Intraductal carcinomas, however, do express 
measurable quantities of uPA using immunoperoxidase 
detection methods. 22 Measurements of uPA by absorption 
of immunologic stains as light passes through tumor cells 
usually is recorded by the image analysis system as the 
mean optical density of groups of cells in the field of 
view. This is more difficult to quantitate, especially for 
individual cells, since light absorbed by the 
histopathology counterstains adds to the absorption of the 
uPA antibody labels. Measurements of fluorescence is a 
better quantitative method since the light is emitted only 
from the uPA molecules and at a wavelength different 
from the incident light. Also fluorescent stains are used at 
lower concentrations than absorbing stains, and the net 
background from autofluorescence is less than the 
contribution of nonspecific staining by light absorbing 
stains. 23 Fluorescence emitted from whole cells in 
cytopreps can clearly show the concentrations of uPA on 
the cell membrane as well as “hot spots” within the 
cytoplasm. Figure 5a shows an example of a breast tumor 
section illustrating the areas of uPA found in foci of 
tumor cells. Distinct areas of concentrated uPA are 
shown (white lines). Clearly, many tumor cells are not 
producing significant quantities of uPA and neither are 
most of the normal cells. Thresholding and image 
enhancements can often give size distribution and more 
information on the cells producing the uPA. Figure 5b 
shows the same tissue section as figure 5a; however, this 
image (5b) has been digitally analyzed and pseudocolor 
added to the display to illustrate that considerable cellular 
detail remains obscured in the black and white image in 
5a. These methods can be used in retrospective studies 
where the time to reoccurrence and the degree of 
metastasis and morbidity are known. Cumulative data 
can then be used to provide a prognostic indicator for the 
presence of active metastasis. 


Flow Cytometric Studies of Urokinase in 
Cultured Glioma Cells 

To establish the parameters for comparing 
immunofluorometric analysis of urokinase (uPA) using 
flow and image cytometry, studies were begun with 
normal kidney cells. Once the methods were 
standardized, the cytoprep studies were extended to 
measurement of uPA in U937 lymphoma and human 
glioma cell lines, which were found to produce high 
levels of the plasminogen activator. Several glioma cell 
lines employed in the studies were obtained from 
Dr. Marylou Ingram, Huntington Research Foundation, 
Pasadena, California. These cell lines, which were 
cultured from patient surgical biopsy material, have 
different morphological characteristics and growth rates. 
The first of these lines, CS, grows very rapidly as 
polygonal cells in monolayers and, in the absence of 
serum, tends to form spheroid structures. The second cell 
line, HBR09, has a fibroblastoid morphology, although it 
has the characteristic immunological marker associated 
with gliomas, glial fibrillary acidic protein (GFAP). 24 
This cell line grows at about 25% the rate of CS. 

Initially, some problems arose with autofluorescence 
from the cells which interfered with uPA quantitation. 
Optimized methods allowed measurement of significant 
differences in the immunostaining with the anti-uPA Mab. 
Dual staining with propidium iodide (PI) following 
ribonuclease treatment and fluorescein-labeled anti-uPA 
antibodies enabled bivariate analysis of DNA and uPA 
content as shown in figure 6. The graph on the left is a 
plot of numbers of cells versus DNA content (abcissa), 
which reflects the distribution of cells in different stages 
of the cell cycle. The plot on the right shows the uPA 
content (ordinate) and the same relative DNA content 
(abcissa, different scale). It is clear that most of the cells 
in G1 and all of the cells in S phase have very high 
levels of uPA. 

We are comparing flow cytometric analysis of uPA 
levels in several glioma cell lines. Similar FCM graphs of 
DNA and uPA fluorescence in the CS cell line are shown 
in figure 7. In contrast to the HBR09 cells (fig. 6) a 
majority of these cells in G^ and in S phase have much 
lower levels of uPA (right-hand plots). Both glioma cell 
lines produce uPA during growth and also during 
stationary (Gl/GJ phase, with HBR09 producing 
significantly higher levels of intracellular uPA. The 
higher levels of uPA in the HBR09 line indicate more 
active metastatic potential than cells with lower uPA 
levels. The relative levels of uPA as measured by 
immunofluorescence flow and image cytometry are 
tabulated in table 1. The HBR09 cells have considerably 
more variability in the uPA (fluorescence) measurements 
than do the CS cells, and the HBR09 cells also appear to 
produce more membrane-bound uPA (based on 
qualitative examinations of some 150 cells); however, 
quantitative measurements are still under way. Further 
studies are concentrating on image cytometry 
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measurements of uPA to better quantify the membrane- 
bound (receptor) versus cytoplasmic uPA since flow 
cytometry only measures fluorescence at "zero 
resolution.” 

DNA can also be quantified on a per-cell basis using 
image analysis. However, when using PI for DNA and 
fluorescein label for uPA, the amount of DNA 
fluorescence was often more predominant than the uPA- 
related fluorescence (green wavelength) since PI 
fluorescence overrides FITC emissions. This required 
adjustment of the incident light intensity to keep both 
fluorescence signals in the same range to avoid resetting 
the video camera sensitivity between measurements on 
the same field of view. DNA quantitation can be 
performed more effectively by staining a dye excited in 
the U.V. (Hoechst 33258) and analyzed in the blue region. 

Discussion 

The importance of urokinase as a key enzyme in the 
initial mechanisms leading to tumor cell invasion and 
metastasis has been underscored in the past three years. 
Previous methods of measuring extracted uPA /mg of 
protein or of measuring secretion levels in cultured 
explants have provided statistical correlation with 
disease-free and overall survival. 25 There also is a strong 
correlation between uPA production and lymph node 
status in breast cancers and multivariate analyses have 
shown that high levels of both uPA and PAI-1 mean a 
maximum risk of relapse. It is now time to develop more 
specific tests that can accurately determine the active uPA 
versus the inactive scuPA, the membrane-bound uPA and 
the PAIs that appear to have interlinked, critical roles in 
the migration and metastasis of breast and other cancers. 

The first research step has been to compare the DNA 
measurements and the intracellular levels of urokinase in 
tumor cells and normal cells. The initial FCM analyses 
will determine the effect of cell cycle on those cells 
having elevated uPA and the general relationship between 
abnormal DNA and uPA in breast and brain tumors. 
Additional data is being collected on DNA synthesis rates 
and uPA levels using more specific flow cytometry and/or 
image analysis techniques. Urokinase levels can be 
determined in those subpopulations of tumor cells that 
have abnormal DNA (using two parameter flow 
cytometry). We currently are measuring the intracellular 
and membrane-bound levels of urokinase per cell using 
fluorescent anti-uPA antibodies and image analysis. 

Next, different forms of uPA and uPA receptor complexes 
will be measured using molecular-specific antibodies. 
Finally, measurements of PAI-1 or PAI-2 per cell are 
compared to the abnormal DNA and high uPA to 
determine the final relative metastatic potential. 
Correlations with hormone receptors and other proteolytic 
enzymes also can be made to provide additional 
prognostic information for custom design of adjuvant 
therapy following surgical removal of the primary tumor. 


Commercial Applications 

Many intricate biochemical interactions are involved 
in dissolution of the extracellular matrix, which enables 
metastatic cells to leave the primary tumor. Intracellular 
metabolism appears to have a major role in the initiation 
of cellular metastasis. The complexity of these 
interactions makes it too complicated for laboratory test 
kits to be effective in routinely measuring the DNA, uPA, 
PAIs, hormone receptors, etc., necessary to develop a 
comprehensive prognostic panel for a particular cancer 
patient. Such a task requires a specially equipped, expert 
medical testing service where pathologists, surgeons and 
oncologists can send patient biopsies for complete 
analysis. Several companies already offer this type of 
cancer testing as a commercial service; however, tests for 
uPA as a prognostic marker of metastatic potential are not 
yet offered. Once the metastatic relationships are 
characterized at the cellular level, clinical studies will be 
required to statistically correlate these biochemical tests 
with recurrent disease and survival. Quantitative 
measurements of uPAs, uPA receptors, and inhibitors can 
be added to the existing panel of breast cancer cytological 
tests. The first use of these tests will be in providing 
additional information that indicates active metastasis at 
the time of initial surgery. This information can help 
oncologists design better, more effective followup therapy 
for those patients who have high levels of multiple 
markers indicating metastasis is already under way even 
though clinical manifestations are still undetected. 

This NASA-sponsored project is developing methods 
for a routine analytical test of intracellular and membrane- 
bound uPA that can be added to the existing panel of 
breast cancer markers. Each year more than 170,000 new 
breast cancers are discovered in the U.S. alone. 
Unfortunately, about 30% of these patients will die from 
their breast cancer. 24 The current tests for DNA content, 
DNA synthesis and hormone receptors cost about $350. 
More complicated tests will likely cost $450 each. A 
practical test for urokinase combined with other 
metastatic markers of breast cancer would create a 
significant new market for cancer testing laboratories. 

And of course, uPA is important in many other types of 
metastatic cancers. Better adjuvant therapy, used only 
when critical markers are known to indicate active 
metastasis, could make a significant impact on the 
survival of cancer patients and reduce medical costs 
required to treat recurrent disease. 

Finally, antibodies specific against urokinase can be 
used for more than diagnosis of the beginning steps of 
metastasis. As the entire scenario is better understood, it 
may be possible to develop treatments targeted against 
just those metastatic cells that have large amounts of 
membrane-bound urokinase or large concentrations of 
inactive scuPA. Anti-uPA antibodies could be conjugated 
with antitumor drugs or radioisotopes to treat specific 
metastatic cells that are actively trying to invade adjacent 
tissues. This could be the basis for the first therapy 
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directed against metastatic cells that were not removed by 

cancer surgery or that had begun migration prior to 

removal of the primary tumor. 
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Table 1. Urokinase Levels in Glioma Cell Lines Measured by Immunofluorescence Flow and Image Cytometry. 



MEAN FLUORESCENCE ±S.D. 


CELL LINE 

FLOW CYTOMETRY 

IMAGEANALMS. 

CS 

6.13 ± 0.10 

11.3 ± 0.86 

HBR09 

32.25 ±11.3 

74.1 ± 6.34 


scuPA 

(inactive) 



» Proenzyme 
^Xactivation 


Plasminogen 


uPA receptor 


uPA - receptor 
complex 




activation^ 


ACTIVE uPA 



Plasmin 


RAPID 


METASTASIS 


INVASION 


PROTEOLYSIS of 
Basement membrane 

Extracellular matrix ... 


i. 


activation I of proteases 


( 


Collagenases 
Laminas es 


Figure 1. Schematic of Urokinase Secretion, Inhibitor (PAI-1), uPA Receptor, Activation of Plasmin and Subsequent 
Protease Steps That Enable Tumor Cell to Lyse the Extracellular Matrix, Invade Adjacent Tissues and Metastasize. 
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Figure 2. Conceptual Comparison of Current Method to Measure Extracted Urokinase and the NASA Flow and 
Image Cytometry Analyses That Are Being Developed into a New Metastatic Assay for Commercial Cancer 

Testing. 
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Figures 3a and 3b. Photomicrographs of Human Glioma Cells Stained for Urokinase (uPA) by Rhodamine Labeled 
Antibodies. Note the Intense Fluorescence in Localized Areas of Concentrated uPA. 
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Figure 4. Digital Pseudocolor Image of Glioma Cells Labeled with Rhodamine-Conjugated Anti-Urokinase 
Antibodies. Concentrated uPA Bound to the Cell Membrane is Shown by Intense Fluorescence Along the 
Margin of Two Cells (White Lines) and Throughout Most of the Other Two Cells (Upper and Lower Left). 
Quantitative Measurements are Performed by Density Slicing Then Measuring Fluorescence Intensity and 
Relative Area for Statistical Comparisons Among Biopsied Cells. 
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Figure 5a. Digital Image of Breast Histology Section Showing Tumor Cells and uPA Labeled with Antibodies. Mean 
Optical Densities are Measured and Normalized for Area to Measure the uPA (Fluorescence Intensity) in the Active Cells. 



Figure 5b. Color Enhanced Image of 5a Showing the Additional Morphological Information That Is Recorded But Not 
Evident in the Black and White Image Above with Only One Density Slice Colored for Contrast. 
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CELL HO. o Z r- r- m o 





MIN. MAX 

PERCENT MEAN FL. 

SD SHPCY 

1 X 

0 13 

82.6 

9.9 

1.0 

7.26 

Y 

3.24 1023 


12.2 

0.17 

8.62 

2 X 

14 63 

15.0 

17.4 

2.2 

13.2 

Y 

3.24 1023 


15.48 

0.18 

10.9 

3 X 

0 13 

2.2 

9.5 

1.1 

9.59 

Y 

0.102 3.24 


12.16 

0.26 

4.08 


Figure 6. Flow Cytometry Immunofluoresence of Glioma Cells (HBR09 Line) Labeled with Propidium Iodide (PI) for 
DNA and Fluorescein-Conjugated Antibodies for Urokinase (uPA). Panel A Shows the DNA Histogram of These Cells 
ith Gj, S and G 2 + M Subpopulations. Panel B Compares the uPA and DNA Fluorescence for Cells in G x (82% of Total), 

in S Phase (15% of Total) and in G 2 + M (22% of Total). 



DNA FLUORESCENCE 


DNA FLUORESCENCE 


Figure 7. Flow Cytometry Analysis of CS Cell Line for Comparison with Figure 6. Panel A Shows the CS Cell Cycle 
Distribution of DNA Fluorescence (PI). Panel B Shows the Fluorescence Distribution of uPA versus DNA. Most of the 
Cells in G t Phase (22% of Total) and in S Phase (7% of Total) Contain Significant Levels of uPA. 
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Abstract 

Decompression Sickness (DCS) is due to the 
formation of a free gas phase in the form of microbubbles 
in tissues during decompression to reduce ambient 
pressure. The microbubbles so formed are frequently 
detectable in the precordial location using a Doppler 
ultrasound device. These circulating microbubbles (CMB) 
are frequently detected in individuals presenting with 
symptoms, but not all individuals with CMB develop 
symptoms. This study used survival analysis techniques to 
examine the association between time to detection of 
CMB and time to onset of symptoms. Survival analysis is 
commonly used in chronic disease (such as cancer) 
epidemiology. 

Materials and Methods 

The records were examined for 125 test subjects 
(100 men and 25 women) who participated in the NASA 
hypobaric chamber trials, which studied the risk of DCS 
during extravehicular activities (EVA). The subjects 
breathed 100% oxygen at site level for periods ranging 
from 0 to 6 h as a protective measure for DCS. Eighty 
percent of the subjects were exposed to an altitude of 
9,144 m (30,000 ft) and the rest were exposed to an 
altitude of 6,400 m (21,000 ft). All subjects breathed 
100% oxygen at altitude and exercised for 180 minutes, 
simulating EVA work at rates approximating 200 KCal/hr 1 . 

For comparison of individual characteristics, as well 
as of times to onset, we used non-parametric methods 
such as chi-square and Mann- Whitney’s rank sum tests. 

To investigate the study question, we used survival 
analysis methods including Cox proportional hazards 
regression. 1 

Since the prognosis under decompression changes 
with detectable microbubbles, CMB status was used as a 
“time-dependent” covariate. 1 ’ 2 Individual CMB status 
was coded as 0 before and 1 after the detection of 
microbubbles. Age (<32 and >32 years), gender (male and 
female), body mass index (<24 and >24), activity levels 
(active and inactive), exposure altitude (6,400 m and 
9,144 m) and duration of ground-level denitrogenation 
(nil, 3.5 h, 4.0 h, and 6.0 h) were used as covariates in the 
regression. 

A subgroup regression analysis was also carried out 
on individuals with CMB (n=49) using time to detection 
of CMB (<60 min=early and >60 min=late) and other 


variables discussed above. All p-values <0.05 were 
considered statistically significant. 

Results and Discussion 

Of 125 individuals, 18% presented with symptoms of 
DCS (all type I, bends pain) and 42% with symptoms of 
CMB. There were significant differences in the CMB 
status (present or absent) and in the time to detection of 
CMB between individuals with and without symptoms of 
DCS (table 1). 

The Cox regression analysis showed heterogeneity in 
the risk of symptoms of those with and without CMB. 
Individuals who developed CMB were at higher risk 
(relative risk [RR]=29.56; 95% confidence interval [95% 
CI]=7.66-1 14.27) of developing symptoms than those 
without CMB. 

In the subgroup of individuals with CMB, there was a 
reduction in the risk of symptoms with late onset of CMB 
(RR=0.92; 95% 0=0.89-0.95), compared to early onset 
(table 2). 

Precordial Doppler ultra-sonography is frequently 
used to monitor the severity of decompression, but the 
temporal relationship between CMB and symptoms has 
not been examined in detail before. The analysis of the 
effect of time to onset of CMB on symptoms of DCS is 
confounded by several factors. The information on 
symptoms is usually incomplete or "censored” since not 
all subjects present with symptoms during an exposure. 
Further, the influence of one failure time (time to onset of 
CMB) on another failure time (time to symptoms) is not 
amenable to traditional methods of analysis. 

Survival analysis uses both complete and censored 
information. Survival models account for the influence of 
failure due to CMB on the failure due to symptoms by 
using a time-dependent covariate in the analysis. 2 Using 
this approach, we found that individuals with CMB were 
at greater risk of symptoms. Delayed onset of CMB was 
associated with a reduced risk of symptoms. This 
reduction in risk may be due to the lesser amounts of 
dissolved gas available for growth of microbubbles after 
prolonged stay at altitude. 

It appears that differences in time to detection of 
CMB are a measure of the individual’s propensity to 
develop symptoms. The use of survival methods provides 
a way to examine the association between symptoms and 
microbubbles in the presence of censored information. 
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Table 1. Comparison of Baseline Factors by Symptom Status 



Symptoms Present 
(n=22) 

Symptoms Absent 
(n=103) 

p-values 

Age in years 

34.4 (7.7) 

31.4 (7.1) 

0.09 

Body mass index 

23.9 (2.7) 

23.9 (2.7) 

0.83 

Activity levels 

4.5 (2.5) 

4.5 (2.5) 

0.99 

Time to CMB in 
minutes 

61.9 (33.2) 

150.8 (50.5) 

0.001 

Gender 

Male 

20 (91%) 

80 (78%)' 


Female 

2 ( 9%) 

23 (22%) 

0.13 

Final Altitude 

18 (82%) 

82 (80%) 


9,144 m 
6,440 m 

4 (18%) 

21 (20%) 

0.81 

Prebreathe 

4(18%) 

21 (20%) 


Nil 

10 (45%) 

24 (23%) 


3.5 h 

5 (23%) 

23 (22%) 


4.0 h 

6.0 h 

3 (14%) 

35 (35%) 

0.12 

CMB 

22 (100%) 

30 (29%) 


Present 

Absent 

0 - 

73 (71%) 

0.001 


Table 2. Relative Risk of Symptoms in the Subgroup of Individuals with CMB 


Time to Onset of 
Microbubbles 

Symptom Present 
(n=30) 

Symptom Absent 
(n=19) 

Relative Risk 
(95% Cl) 

<60 minutes 

10 

12 

1.00 

>60 minutes 

9 

18 

0.92 

(0.89-0.95) 


95% 0=95% Confidence Interval; * p<0.05 
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Abstract 

The findings of recent investigations in 
environmental physiology indicate a need for extensive 
changes in those sections of JSC Management Directive 
1830.3, “Limitations Applicable to Personnel Exposed to 
Diving,” which concern flying after diving. Because 
development of safe pressure/time exposure profiles is 
largely an empirical process, it would be highly desirable 
to verify the new tables calculated under laboratory 
conditions during the revision of this Management 
Directive. This study verifies the safety of profiles from a 
portion of these tables which is particularly relevant to 
operational concerns. Specifically, 19 human subjects 
were exposed to a pressure of 1.59 atmospheres absolute 
pressure (ata; 161 kPa, equivalent to a depth of 6.1 m) for 
400 min, then to 1.0 ata (101 kPa) for 14 h, then to 
0.69 ata (69 kPa, equivalent to an altitude of 3048 m) for 
180 min. Air was breathed throughout. Precordial 
Doppler ultrasound monitoring for intravascular gas 
emboli (an indicator of the development of 
decompression sickness(DCS)) was performed at selected 
points during the exposures to 1.0 ata and 0.69 ata. Any 
signs or symptoms of DCS were noted. None of the 
subjects developed DCS, although four subjects exhibited 
high grade (grade III or IV) Spencer Doppler scores at 
some point during the hypobaric excursion. Through 
comparisons of these results with those of previous 
studies, we conclude that in this profile the risk of 
developing DCS, which would require hyperbaric 
therapy, is probably less than 1% per person-exposure. 

Introduction 

Relative to typical diving practices, neutral buoyancy 
training, involves a host of peculiar factors. For example, 
following training, the T-38 aircraft can be used as a 
means of transportation. This aircraft is often flown at 
high altitudes utilizing a differential cabin pressure, which 
is considerably less than that of aircraft operated by major 
air carriers (34 kPa versus 55 kPa differential pressure, 
respectively). Flight in a T-38 after a very long, shallow 
dive is a wholly unique scenario, and very little relevant 
data are available from any source. In the absence of such 
data, procedures could be formulated utilizing highly 
conservative assumptions. However, access to a T-38 
offers obvious, substantial operational benefits, and 
unnecessary restrictions on such flying are to be avoided. 

Rules regarding diving and flying after diving are 
stated in JSC Management Directive 1830.3, “Limitations 


Applicable to Personnel Exposed to Diving.” Results 
from recent investigations in environmental physiology 
indicate a need for extensive changes in the sections of 
this document which deal with flying after diving. 
Because development of safe pressure/time exposure 
profiles is largely an empirical process, it would be highly 
desirable to verify, under laboratory conditions, the new 
tables calculated during the revision of this Management 
Directive. This study investigated the risk of 
decompression sickness which is particularly relevant to 
current operational concerns. 

Problem Statement/Description 

Human subjects were exposed to a pressure of 
1.59 ata (161 kPa) for 400 min, then to 1.0 ata (101 kPa) 
for 14 hours, and then to 0.69 ata (69 kPa) for 180 min. 
Air was breathed throughout. Precordial Doppler 
ultrasound monitoring for intravascular gas emboli (an 
indicator of the development of decompression sickness) 
was performed at selected points during the exposures to 
1.0 ata and 0.69 ata. Any signs or symptoms of DCS 
were noted. 

We hypothesized that an interval of 14 h at 1 ata, as 
described above, would result in a risk of DCS which 
would require hyperbaric therapy. This risk would not 
exceed 1 % per person-exposure over the course of all 
phases of the pressure/time profile. 

Methods 

The essential elements of the experimental protocol 
are as follows: 

• A hyperbaric exposure to a pressure of 1.59 ata 
(161 kPa) for 400 min while breathing air. This was 
followed by: 

• An interval at 1 ata for 14 h while breathing air. This 
was followed by: 

• A hypobaric exposure to a simulated altitude of 
3,048 m (10,000 ft) for 3 h while breathing air. 

During the hyperbaric portion of the experimental 
protocol, a series of exercises was performed that 
simulated the workloads involved in extravehicular 
activities. The subjects engaged in their daily activities 
during the surface interval between hyperbaric and 
hypobaric exposures, except that exercise training was 
prohibited. Air was breathed throughout the surface 
interval. While at simulated altitude, the subjects 
remained comfortably seated and performed no specific 
exercise. 
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Results were quantitated as follows: Any signs or 
symptoms of DCS were noted. Additionally, precordial 
Doppler ultrasound monitoring for circulating gaseous 
microemboli was performed in each subject for 5 min 
every 30 min for 1 h following the hyperbaric exposure 
and throughout the hypobaric excursion. Doppler signals 
were assigned a numerical grade. lA3 Further analysis of 
these signals was performed utilizing the “time-intensity” 
method 4 . Acquisition and processing of Doppler 
ultrasound data in this manner yielded far more data than 
arises from a simple “bends/no bends” scoring method, 
thereby permitting establishment of conclusions after a 
minimum of experimentation and expense. 

Nineteen volunteers participated. They were healthy 
adult men and women in the age range of 25 to 55 yr. 

The subjects were selected to match the astronaut 
population as closely as possible in age, gender, height, 
weight, body surface area, percent body fat, and physical 
fitness level. Individuals having conditions or injuries 
that may have made them predisposed to DCS, as well as 
candidates with a history of neurologic DCS, were 
excluded. All subjects executed informed consent 
agreements and were free to withdraw from the project at 
any time. 

Results 

No subject exhibited signs or symptoms of DCS. 
Maximum precordial Spencer Doppler bubble grades 
achieved are as follows: 

Maximum Grade Number of Subjects 

0 9 

1 3 

II 3 

III 1 

Conclusions 

Interpretation of these data is difficult because the 
risk of DCS implied by a given Spencer Doppler bubble 
grade in a combined hyperbaric and hypobaric pressure/ 
time profile is not known. In our study 4 of 19 subjects 


demonstrated high bubble grades (grades III or IV)* This 
incidence is similar to that observed by Eckenhoff et al., 5 
following saturation exposure at a pressure of 1.48 ata 
(150 kPa), a profile which carries a risk of DCS below 1% 
per person-exposure. Based upon this comparison, we 
conclude that the risk of DCS requiring hyperbaric 
therapy in this profile is probably less than 1% per 
person-exposure. This conclusion must remain tentative 
until a larger data base is developed which permits 
correlation of bubble grades with risk of DCS in 
combined hyperbaric and hypobaric profiles. 
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In-flight echocardiographic measurements of 
astronaut heart function on the Space Shuttle have 
documented a 15% to 20% reduction in stroke volume 
with a compensatory increase in heart rate to maintain 
cardiac output. To date, no mechanism for the reduced 
stroke volume has been elucidated. We propose that the 
reduction in stroke volume is biophysical in origin. 

Many factors influence the filling of the heart during 
diastole (fig. 1). These factors include 

• the atrial pressure, 

• the kinetic energy of the blood as it enters the ventricle, 

• the transmural pressure gradient, 

• the passive, elastic recoil attributed to the “parallel 
elastic element” of the myofibrils, and 

• the gravitational acceleration-dependent hydrostatic 
pressure gradient that exists in the ventricle due to its 
size and anatomic orientation. 

This pressure gradient, which can be estimated to be 
6660 dynes/cm 2 (-5 mm Hg) in an average adult, acts to 
augment the diastolic filling of the heart. It has been 
estimated that the effect of this pressure component 
contributes between 10% to 30% of the total ventricular 
filling. We hypothesize that the absence of this 
contribution to the ventricular filling process in the 
microgravity environment of spaceflight may account, in 
part, for the 15% to 20% reduction in stroke volume 
reported for astronauts while in orbit. 

To test this hypothesis, ventricular function test were 
conducted using an artificial heart (AH) left ventricle with 
the longitudinal axis anatomically oriented (@45° to the 
horizontal) and horizontally oriented to null the 
hydrostatic pressure difference (AP) between the base and 
apex of the ventricle. Additional ventricular function test 
were conducted in the microgravity environment of the 


NASA KC-135A aircraft. The experimental apparatus 
consisted of a pneumatically actuated, elliptical artificial 
ventricle (UTAH-100 human version left ventricle) 
connected to a closed-loop, hydraulic circuit (Penn State) 
with compliance and resistance elements to create 
physiologic pressure and flow conditions. The ventricle 
was instrumented with high-fidelity, acceleration- 
insensitive, catheter-tip pressure transducer (Millar 
Instruments) in the apex and base to determine the 
instantaneous ventricular pressures and AP across the left 
ventricular (LVP^ - LVP^. The ventricle was also 
instrumented with flow probes (Transonic Systems) and 
pressure transducer (Millar Instruments) immediately 
upstream of the inflow valve and downstream of the 
outflow valve. By varying the circulating fluid volume, 
ventricular function was determined for varying payload 
pressures with fixed afterload pressure and ventricular 
control parameters. 

Elimination of the intraventricular hydrostatic AP 
between the ventricular apex and base by horizontally 
aligning the ventricle or ventricular operation in the 
microgravity environment resulting in the predicted 
rightward shift of the ventricular function curve (Fig. 2 
and 3). This finding offers a biofluid mechanical 
explanation for changes in AH recipient cardiac output 
with changes in posture and suggests new AG automatic 
control parameters to maintain a consistent cardiac output 
with changes in AH recipient posture. Furthermore, these 
results indicate the need to document AH pumping 
performance in extremes of device orientation. Finally, 
this finding provides a biofluid mechanical explanation 
for the reduction in cardiac stroke volume experienced by 
Space Shuttle astronauts while in orbit as documented by 
echocardiography. 
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Abstract 

An accurate human computer reach model capable of 
simulating complex 3-dimensional tasks would be a 
valuable tool in the evaluation of workspace volumes. 

This model could be used to design workstations, 
configure hand holds/foot restraints, and simulate realistic 
motions on Earth and in microgravity environments. The 
most kinematically complex interaction to model in the 
human arm is the shoulder girdle. The motion of the 
shoulder complex involves several joints moving 
simultaneously, with a complicated and dependent 
interaction. This shoulder motion was measured in all 
rotational planes using a magnetic tracking device. These 
measurements were used to validate and refine a clavicle/ 
shoulder kinematic model. Accurate relaxed reach 
positions can now be computed in all planes of motions to 
within, on average, 1 cm of the measured data. 

Introduction 

Essential to accurate reaching with the arm is a 
comprehensive model of the shoulder girdle. The 
complexity of the shoulder motion and the 
interdependence of the joints affecting the shoulder 
complex have been studied for years. 1 Inman, Saunders, 
and Abbott measured and documented the complex 
motions of the shoulder girdle to include four different 
joints: the stenoclavicular, the acromioclavicular, the 
scapulothoricic, and the glonohumeral. The motion of the 
shoulder complex is due to the combined motion of all 
these joints. The model we use simplifies the shoulder 
motion into two joints, a clavicle joint and a humerus 
joint. Neither of the two joints in the model necessarily 
represents their corresponding anthropometrically correct 
position in the shoulder complex. Nevertheless, this 
simplification still allows the prediction of accurate 
motions. 

Early computer models have had a clavicle joint with 
two degrees of freedom and a humerus joint with three 
degrees of freedom. These models did not have an 
automatic clavicle/humerus interaction. Often the 
clavicle joint motion was ignored because of the difficulty 
in moving both the upper arm and the clavicle 
independently. This has led to unrealistic reach volumes 
and motions. E. M. Otani developed equations relating 
the clavicle motion and humerus motion to the elevation 
and abduction of the shoulder complex. 2 Measurements 
of reach sweeps were compared with the Otani model’s 
calculated reach sweeps in an attempt to validate his 
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model. There was an unacceptable 10-15 cm error in the 
computed reach sweeps. Modifications of model 
parameters were made to reduce these errors. 

Methods and Measurements 

Experimental Setup 

Measurements of reach sweeps were obtained using 
a low-frequency magnetic tracking device (Polhemus 
Navigation Sciences, McDonnell Douglass Electronics 
Company). This device was integrated with a Silicon 
Graphics Workstation and an in-house software package 
to allow quick, accurate data flow from the tracker 
directly into the Graphics Analysis Facility’s modeling 
programs. A magnetic sensor was secured to the upper 
arm near the elbow joint and provided positional 
information relative to a fixed coordinate system. A 
wooden frame was built to hold the magnetic source, 
reducing distortions in the magnetic field caused by metal 
in the environment. This frame was elevated to shoulder 
height to have maximum sensitivity over the range of the 
arm sweeps. A study of the limitations of the tracking 
system was done to determine the accuracy of the setup. 
Measurements taken showed an error of less than 1.5 cm 
in the range of our measurements (1 m). Beyond this 
range, the measurements were inconsistent. Attached to 
the wooden frame was a wooden rod used to stabilize the 
subjects. Each subject was positioned with this rod 
centered in his back and was directed to keep his back 
secured against this rod at all times during the sweep. 

This minimized the upper body motion during the sweeps 
and still allowed natural (unconstrained) motion. 

Repeated sweeps over the range of motion of the subject 
in three orthogonal planes were recorded: a forward 
sweep, a side sweep, and a horizontal sweep. In addition, 
horizontal and random stretched (extreme) sweeps were 
also collected. 

Clavicle/Shoulder Model Development 

Model Overview The motion of the shoulder 
complex can be described in spherical coordinates by 
determining the elevation angle (el) and the abduction 
angle (ab) of the end effector (elbow, or fingertip) (fig. 1). 
The model computes the clavicle angles of elevation (c el ) 
and abduction (c^ given the shoulder angles. The 
humerus angles of elevation and abduction are calculated 
from the geometry to position the arm at the determined 
shoulder complex elevation and abduction. 
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Determining Joint Center of Rotations A 

major concern in the accurate characterization of the 
shoulder complex is the location of the joint centers of 
rotation of the clavicle and the humerus joints. The 
previous computer model placed the rotation points of the 
clavicle joint and humerus joint at the physical locations 
of both ends of the clavicle bone in the human figure. 
However, allowing the shoulder clavicle complex to 
rotate at these points generated reach envelopes which 
were much larger than measured. Figure 2 shows side 
sweeps generated with and without joint center lowering. 
The lower portions of the computed sweeps fit the 
measured data. However, the horizontal and the vertical 
regions have unacceptably large errors. To resolve this 
discrepancy, the joint centers needed to be adjusted. In 
order to determine the optimal joint center location for 
each individual, we used an iterative process. Figure 3 
shows the maximum and average errors resulting from 
lowering the clavicle and humerus joint centers for a 
particular individual. Optimal values were selected for 
each individual based on these plots. The lowering of 
both the clavicle and humerus joint centers by the 
appropriate amount allowed for the entire side sweep to 
coincide with the measured data. 

Modifications to Model Parameters The 
dependence of the clavicle elevation on arm elevation was 
established by Otani by fitting regression equations to 
empirical data collected by Inman. The clavicle elevation 


angle in degrees is 

Qi * cos(ab)* 61 + (l-cos(ab))*82 - 90.0 (1) 

where 

61 = 0.2514*el + 91.076 for 0 s el s 131.4 (2) 

61 = -0.035*el+128.7 for el > 131.4 (3) 

and 

62 = 0.21066*el + 92.348 for 0 *elsl20.0 (4) 

62 = 120.0 for el > 130.0 (5) 


Otani’s model of the clavicle abduction angle was simply 
a linear dependence on the shoulder abduction, that is 

c ab= coef *ab (where coef = 0.2) (6) 

As the arm is elevated or lowered from the horizontal 
position, the clavicle abduction angle decreases. This fact 
necessitates that the clavicle abduction equation also be 
dependent on shoulder elevation. 

c a b = coef * ab * sin(el) (7) 

Equation 7 allows for smoother motions of the 
clavicle abduction to occur. As the shoulder moves 
through 0 or 180 degrees the clavicle abduction angle 


moves through 0 without a discontinuous motion. 

Modeling Stretched Versus Relaxed Motions 
The clavicle angles (elevation, abduction) are important in 
the modeling of relaxed versus stretched motions of the 
arm. The parameters associated with these motions were 
studied in detail. The abduction of the clavicle (c^ was 
observed to be directly related to the coefficient term in 
equation 7. The coefficient (coef) term correlates to the 
physical ability of individuals to stretch their clavicle 
joints in the horizontal plane (abduction). Individuals can 
increase the clavicle abduction angle for a specific 
position by stretching. It is difficult to do this while 
maintaining a sweeping motion. But when a specified 
point in space is the goal, individuals can increase their 
clavicle abduction angle and hence increase their reach 
envelope. This parameter can be empirically determined 
for an individual and differs if the reaching characteristics 
are relaxed or stretched. 

The elevation of the clavicle (c d ) is dependent upon 
61 and 62 coefficients of the model equations 1-5. To 
model the stretching motion for extreme elevation angles, 
the 61 and 62 coefs were modified to include an extra 
term. 3 These modifications to the clavicle abduction and 
elevation computations enabled the prediction of stretched 
and relaxed reach sweeps for any plane of motion. 

Results 

Excellent fits between the model data and the 
measured data were obtained. Over the range of subjects, 
the average error in fit was 0.96 cm and the average 
maximum error was 3.19 cm. The maximum error refers 
to the single data point with the largest deviation between 
model and measured values. The absolute average 
difference is an average over the entire range of motion 
(150 data points) of the sum of the absolute errors 
between model and measured values. In addition, a 
regression plot of model versus actual reach distances 
(shoulder to end-effector) revealed a correlation 
coefficient of 0.98. This represents a significant 
improvement over the previous reach model. 

Parameter estimation for the model is central to 
achieving accurate reaching. Three parameters were 
examined in detail: joint center location, the coef term of 
the clavicle abduction equation (eq. 7) and the stretch 
coefficient of the clavicle elevation equations. 

For all subjects, the horizontal relaxed and stretched 
sweeps were compared to determine the best range of 
values for the coef term in the clavicle abduction angle 
calculation (eq. 7). Over the 12 subjects, an average 
relaxed coef of 0.24 and an average stretched coef of 0.62 
were calculated. Extreme elevation angles of the random 
sweeps were used to estimate the best fits for the stretch 
coefficient. Further validation of these parameters needs 
to be done in order to determine accuracy of predicting 
reach sweeps for any subject. 
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Conclusions 
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Figure 1. Shoulder Kinematic Model Overview. 
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Figure 2. Measured Versus Computed Reach Sweeps 
(With and Without Joint Axis Correction). 
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Abstract 

Extravehicular activities performed in space require 
proper lighting conditions. The placement and properties 
of lights and materials used are highly constrained by 
factors which include power consumption limits, head 
dissipation issues, and available space. An accurate 
lighting model capable of simulating complex 3- 
dimensional environments would be a valuable tool for 
space applications. This model could be used to deal with 
complex visibility issues and aid in the optimum selection 
of lights, materials, and viewing perspectives for space 
operations. 

A variety of lighting simulation packages are 
available. This report describes the limitations and 
validity of three of these models: “standard” ray tracing, 
“Radiance,” and radiosity. Using empirically collected 
data on material/light properties, a controlled experiment 
and an accurate geometry were set up both in the graphics 
environment as well as in NASA’s Lighting Environment 
Test Facility. Luminance at various points in the 
environment was measured with a photometer and also 
computed in the graphics environment. Modeled versus 
measured values agree to within the limitations of the 
photometric procedures used. This report describes the 
details of the validation study. 

Introduction 

Geometric modeling and viewing of structures is 
commonly used in aerospace engineering. The analysis 
of lighting conditions is the next logical extension for 
realistic viewing analysis. When determining the lights, 
viewing perspective, and materials used for a particular 
mission, many issues including power consumption 
limits, heat dissipation issues, and available space are 
carefully considered. Recently, computer graphics 
lighting models have been used by the Space Station and 
Shuttle community. Design decisions have been 
recommended based on these studies. If these models are 
employed without understanding the basic assumptions 
and approximations used by the simulation and without 
validation of the results that they produce, some 
potentially serious problems could arise. This concern 
has provided the thrust to research and validate computer 
models used for these lighting applications. 

Three classes of models were chosen for validation: 
standard ray tracing, “Radiance,” and radiosity. The 
standard ray tracing (Rshade) program by Craig E. Kolb 
(Princeton, New Jersey) traces light from the eye point to 


the light sources in the environment while reflecting the 
rays in accordance with surface properties. Radiance by 
Greg J. Ward (Lawerence Berkeley Laboratory, 
California) extends the ray tracing method by using a 
Monte Carlo technique to compute interreflections 
between surfaces. Radiosity by Min-Zhi (University of 
Pennsylvania, Pennsylvania) computes a view- 
independent lighting solution, which balances the energy 
flux of each surface with respect to every other surface in 
the environment. 

Major issues of concern for realistic space 
applications were the modeling of interreflections 
between surfaces, the handling of large complicated 
geometry, and the ability to compute luminance values at 
any point in the environment. A simple geometric 
experiment was set up both in the graphics environment 
and in NASA’s Lighting Environment Test Facility to 
investigate the problems associated with these lighting 
models. Luminous flux at direct and interreflected 
surfaces was measured with a photometer and also 
computed in the graphics environment. The ray tracing 
and the radiosity algorithms were found to be inadequate 
for realistic space applications. The Radiance algorithm 
computed the interreflections to within the accuracy of the 
measuring device and could also handle complex 
environments. The results presented here show that 
lighting can be accurately simulated for space 
applications with the Radiance model. 

Methods 

Phase 1 

The three lighting models were compiled on a Silicon 
Graphics VGX machine. A set of programs was 
developed to output geometry, transformation 
information, material properties, and light information 
from an in-house geometry modeler (DMC) into formats 
specific to each of the light modeling programs. A simple 
geometry, consisting of a room with two cubes and a light 
source, was then created and used as input to the various 
model formats. Figure 1 shows the geometry that was 
created. This top view illustrates the arrangement of the 
cubes, the light source, and the viewing vector. The light 
source was pointed directly at cube 1. Cube 1 was rotated 
towards cube 2 at a 45 degree angle such that the directly 
illuminated surface of cube 1 would reflect light onto 
cube 2 as illustrated by the dotted light path in figure 1. 
The view was adjusted so that both the directly and 
indirectly illuminated surfaces were visible. 
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Phase 2 

An experimental setup similar to the one run in phase 
1 of the methods was set up in NASA’s Lighting 
Environment Test Facility. The setup included a well 
collimated, small, uniform light source; two 30x30x60 cm 
white boxes; a black curtain; a video camera; and a Model 
301 photometer (Photo Research, Burbank, California). 

A light source was set up 90 cm from box 1, which was 
tilted at a 45-deg angle facing box 2 at a distance of 150 
cm. The video camera was located to view the setup at 
locations all along the perimeter of the experiment. The 
photometer was used to measure the surface reflectance of 
the boxes, the floor, the wall, and the luminance of the 
light source. In addition, photometric measures were 
taken at both the directly and indirectly lit surfaces. 
Careful attention was paid to the geometry of the scene 
and to the view point. The same scene was created in the 
graphics environment and was converted to the Radiance 
format. 

Phase 3 

A test was set up at the Systems Integration Facility’s 
Shuttle Mockup where all lights in the facility were shut 
off except for the Shuttle’s mid and forward payload bay 
lights. Camera views of the payload were recorded on a 
Panasonic video recorder. The Shuttle, with the various 
structures present during the mockup session, was created 
in the graphics environment and outputed to the Radiance 
format. Payload bay light and material parameters for the 
computer model were estimated based on published 
results. 1 

Results 

Phasel 

Of the three modeling packages, radiosity is least 
suited for space applications for the following reasons. 
Radiosity required that the lighting simulation be 
contained within a closed environment due to the 
methodology of the energy flux equilibrium computation. 
In addition, this computation was highly memory 
intensive and was unreasonable for the large detailed 
structures modeled in space applications (i.e., Space 
Station). Moreover, specular reflections could not be 
modeled with the radiocity program. 

Figure 2 shows the output of the other two models. 

In theory, light rays emanating from the source should 
strike cube 1, and depending on the reflectance properties 
of cube 1, illuminate the surface of cube 2. In the ray 
trace image, it is clear that the interreflections are not 
present. The ray trace algorithm can use an arbitrary 
constant term to approximate the indirect lighting of the 
scene. In realistic applications, this term is not constant 
and needs to be computed and not arbitrarily set. On the 
other hand, Radiance output shows the expected result 


without any arbitrary ambient terms. In the Radiance 
view, cube 2 does in fact show the reflected light from 
cube 1. Also, the back right side of cube 1 (away from 
the light) is also illuminated from interreflections off of 
the floor and the walls. 

Phase 2 

Phase two was developed to determine exactly how 
accurate the Radiance program was in its estimation of 
both direct and indirect lighting. Two measures of 
luminance were made, one on box 1 (direct light) and one 
on box 2 (interreflected light). Table 1 shows the light 
and material values measured for the experimental setup. 
Measured versus predicted values are listed in table 2. 
Figure 3 is a comparison of the output of the Radiance 
model with the video camera view of the experiment. 
Radiance output can convert luminance values into a 
color coded image. This allows for a visual analysis of 
the distribution of luminance in the image (fig. 3d). 

Conclusions 

Based on the results in phase 1 of the experiment, it 
was concluded that ray trace and radiosity were not 
suitable for space applications. Radiosity modeled the 
diffuse interreflections, but not the specular, and could not 
handle the large geometry in a nonclosed environment. 
Ray tracing did not handle the interreflections. Light 
striking cube 1 in figure 2 should illuminate cube 2. For 
ray tracing, it does not. Radiance behaved as expected in 
that cube 2 was lit by the reflection from cube 1. Phase 2 
of the experiment was designed to test exactly how close 
the Radiance computation could come to a measured 
value at the direct and indirect surfaces. Table 2 shows 
that the measured and modeled values agreed to within 
the experimental error. The measurement accuracy of the 
light meter is about 10% calibrated for a specific 
wavelength of light. In addition, there are a number of 
simplifying assumptions that have been made in the 
experiment. In order to model the materials in the 
environment correctly, it was required that the 
bidirectional reflectance curves of each material be 
measured. 2 Because the precise equipment necessary for 
that measure was not available, only one measure of 
reflectance, at one angle and at one point, was made. This 
simplification negates the angle dependence of the 
reflectance. For instance, in figure 3 the model view has 
a highly specular reflectance shown at the floor coming 
directly from the light; the actual view is not nearly as 
pronounced. Moreover, assumptions of uniform material 
surfaces, uniform light source, video camera distortions, 
effects of atmosphere, interference from other more 
distant objects in the room, like the ceiling, and the 
persons taking the measurements only add to the error 
expected. After considering all the assumptions and the 
error of measurements involved the computed luminance 
results and the corresponding views from Radiance are a 
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very reasonable estimate of light in the environment. 

Phase 3 of the experiment was an attempt to provide 
a means to extend this work to realistic applications. 
Figure 4 shows model versus actual Space Shuttle view of 
a low lighting situation. Before considering this view, it 
is important to realize that, again, there are even more 
simplifying assumptions used. The material and lighting 
parameters in this environment were estimated from Ref. 
1. Some of the uncertainties, in addition to the ones 
mentioned in phase 2, were related to the following: light 
intensity distribution data used in the model were based 
on detailed measurements of one bay light; this data did 
not correspond exactly to the lights used in the mockup; 
the effects of the rest of the high bay area (ceiling, walls, 
etc.) were not considered; and the view from the camera 
that we used was attenuated by the iris control mechanism 
(its own gamma correction). Considering all the these 
assumptions, the views generated from the model are very 
reasonable. 

Future work needs to focus on validation of even 
more complex lighting situations where the material and 
light properties are more accurately defined. 


In addition, it is imperative that a more rigorous data 
collection effort to extend the data base of light and 
material properties for Space Station Freedom be 
initiated. 
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Table 1. Material Reflectance for Experiment 


Materials 

Illuminance 

Luminance 

%Reflectance 


(footcandles) 

(footlamberts) 


Box 

39.3 

26.0 

66% 

Floor 

235.0 

3.0 

1.3% 

Wall 

255.0 

6.1 

2.4% 


Light source luminance - 136,800 footlamberts. 


Table 2. Validation Results 



Box 1( direct light) 

Box 2 (indirect light) 


(footlamberts) 

(footlamberts) 

Measured range 

6.S-7.9 

0.10-0.12 

Computed range 

3.0- 7.0 

0.05-0.30 
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Figure 1. Top View of Experimental Scene Geometry 


Figure 2. Comparison of Ray Trace and Radiance, 
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Figure 3. Model Versus Actual View of Lighting Experiment. 



Figure 4. Model Versus Actual View of Space Shuttle. 
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Abstract 

As part of the JSC Director’s Discretionary Fund 
Program, a computer-based tool was developed to aid in 
the estimation of the mass and volume of habitable 
elements for advanced spaceflight missions. The tool 
allows its user to define mission and system constraints 
and generates estimates of the mass and volume of a 
habitable element required to support the defined mission. 

Introduction 

The Flight Crew Support Division (FCSD) at JSC 
supplies the agency’s expertise in the integration of 
human crews into spaceflight missions. In this role, 
FCSD provides requirements definition, conceptual 
design, and system development for habitable elements 
which support space crews. 

Advanced missions to the Moon and Mars have been 
under study by NASA for a number of years. The 
Habitation Development Tool (HDT) was created by 
FCSD to support these and future efforts by aiding in the 
definition of flight crew habitation systems. 

Problem Statement 

The definition of advanced spaceflight missions is 
sensitive to the mass and volume of the systems necessary 
to accomplish them. The habitat for a human crew often 
represents one of the largest nonpropulsion elements to be 
launched from Earth; therefore, its mass and volume must 
be estimated early in the mission definition phase in order 
to provide information necessary for sizing launch 
systems. 

Approach 

The HDT was defined as a means for systematic, 
consistent estimation of habitable element mass and 
volume. 

A process was defined for the description of a human 
space mission and the generation of integrated mass and 
volume estimates for the habitable elements necessary to 
support that mission. Figure 1 illustrates this process. 
User and software functions were allocated to define the 
extent of the automated tool. 

Data gathering consisted of a survey of NASA 
experts in the areas of habitable element design and a 
literature search for data needed in the HDT. Experts at 
JSC and other NASA centers were asked to provide data 


which describe the mass and volume of the various 
subsystems of a generic habitable element. These data 
were collected in the form of data bases and algorithms 
which relate subsystem sizing to various mission 
parameters such as crew size, mission duration, and 
resupply interval. 

Detailed data bases of crew accommodations equip- 
ment and consumables were derived from the Apollo, 
Skylab, Space Shuttle, and Space Station Freedom Pro- 
grams. Refs. 1 and 2 were used as sources of Apollo data. 
Refs. 3 and 4 were used as sources of Skylab data. Ref. 5 
was used as a source of Shuttle data. Ref. 6 was used as a 
source of Space Station Freedom data. A subset of the 
Apollo data base is shown in figure 2. 

Recent technology development was used as the basis 
for definition of additional concepts beyond those of past 
spaceflight programs. 

Data describing thermal control, life support, 
extravehicular activity, health care, structural and 
mechanical, information management and 
communications subsystems were provided by experts at 
JSC. 

Data describing the radiation shielding subsystem 
were extracted from refs. 7-10. This data was used to 
create a data base of shielding material thickness versus 
human dose equivalent. Algorithms were defined to 
interpolate values from the data base dependent on 
various user inputs and to calculate a shield mass 
estimate. 

Software development of the HDT included 
integration of the collected data sets and development of 
the user interface. The data collected were formatted as 
Microsoft” Excel tables and macros. The Aldus 
SuperCard” application was used to build the user 
interface. The resulting HDT software is executable by 
the Apple” Macintosh” series of personal computers. 
Lockheed Engineering and Sciences Company personnel 
provided all software development. Figure 3 illustrates 
part of the HDT user interface. 

After development, the HDT was tested by users 
within the JSC Flight Crew Support Division. This 
testing included simulation of various lunar and Mars 
mission scenarios. 

Results 

The HDT has been found to be useful in early, rapid 
estimation of habitable element mass and volume when 
used by a person knowledgeable about human support 
requirements and previous spaceflight programs. This 
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knowledge is essential in making judgements in the 
selection of user inputs to the tool and interpretation of its 
outputs. 

The HDT has also been found to be useful for 
parametric study of the effects of mission parameters on 
habitable element sizing. 

Conclusions 

Systems engineering tools such as HDT are valuable 
in the early phases of program and mission definition. It 
is expected that the HDT will be used in future studies of 
advanced human spaceflight. 

Several areas of the HDT should be developed further 
to increase its value. Some of the current subsystem data 
should be updated to improve its fidelity. Additional user 
selection options should be provided for alternate 
technologies in some subsystems. Integration of some 
subsystem algorithms to improve the simulation of 
interaction effects should also be performed. 
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Figure 1. Habitation Development Tool Process. 
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Figure 2. Subset of Apollo Crew Module Database. 
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Abstract 

Geographic information systems (GISs) are an 
electronically based means for recording, storing, 
manipulating, and presenting information tied to 
geographic coordinates. In interacting with the GIS, the 
user is confronted with a sample of the information 
available in the real world and with a computer medium 
for manipulating that information. It is critical that the 
information be presented in a meaningful manner and that 
the communication with the computer be consistent with 
the task demands of the user. The Human-Computer 
Interaction Laboratory (HCIL) at JSC is examining GIS 
user interface issues from the vantage point of developing 
a working system for JSC’s Space Shuttle Earth 
Observation Project (SSEOP). A description of the 
development of a prototype system and lessons learned 
are reported. 

Introduction 

The HCIL at JSC is currently involved in exploring 
information processing and computer interface design in 
GISs. GISs are computer-based tools for gathering, 
storing, retrieving, analyzing, and presenting geographical 
information. While the GIS concept has been around for 
over 20 years, advancements in computing systems have 
resulted in dramatic increases in the number of users and 
commercial products in recent years. In a survey of GIS 
software producers, the 1991-92 International GIS 
Sourcebook 1 reports a nearly fivefold increase in the 
number of installed systems since 1985. GIS capabilities 
include joining information from sources as varied as 
satellite images, radar, weather reporting stations, and 
seismic data collection sites with records from direct 
human observation. 

A specific GIS application described by Star and 
Estes was used to evaluate water availability and the 
effect of irrigation on crop production in Africa. 2 The 
data considered included rainfall amounts, groundwater 
levels, soil types, and surface slope. Models defining 
water availability and soil potential were applied to the 
available data. The results were mapped on an electronic 
display of African political boundaries. The map 
distinguishes regions requiring irrigation from those not 
needing irrigation, and the expected benefit of irrigation, 
by region. Once the needed data was gathered, these 
activities could be performed on a single system in a 
matter of minutes. 


The GIS buys the user access, time, and flexibility. 
Access to information is increased as a result of linking 
the user to an endless variety of geographically registered 
data. This data can be filtered, sorted, and parsed 
according to the users’ interests. Automated data access 
and management not only save the user time in selecting 
meaningful information, they free the user from time 
spent gathering appropriate paper-based sources from 
reference centers or libraries. The user also enjoys the 
flexibility to revise the selected data set and the 
information displayed. 

Problem Statement 

Human-Computer Interaction Concerns for GIS 

Given what appears to be an ideal system for data 
management, analyses, and display, one might ask what 
remains to be explored? There are two critical interface 
issues that contribute to the productivity of the GIS user. 
The first focuses on the information used in a geo- 
graphical task. The second focuses on the computer as 
the medium through which the information is viewed. 

The information contained in a GIS is a “representa- 
tion.” It is a representation because the information is 
only a sample or subset of the information available in the 
real world. Sampling results in changes of scale, reduc- 
tion of a 3-dimensional object to a 2-dimensional image, 
reduction of context, and limitation to a finite set of object 
characteristics. When a map is drawn at a one pixel to 
one thousand meter scale, each pixel somehow summa- 
rizes all the information about the surrounding thousand 
meter area. That pixel may be defined as having an 
elevation of 500 feet, while the true elevation in the area 
represented may range from 300 to 700 feet. In sampling, 
information is lost and the user is left with questions as to 
the quality of the sample. Spatial and statistical analysis 
methods have been developed to provide summaries of 
sample data and estimates of the error associated with the 
summary. These methods aid the user in determining 
whether what can be “known” from the sample is in 
agreement with what can be “known” from the whole set 
of information. Geographers and statisticians have 
dedicated careers to developing optimal ways of sampling 
and analyzing data. 3 GISs can and should provide 
information about sampling error as demonstrated by An, 
Moon, and Bonham-Carter. 4 

The second critical GIS interface issue relates to the 
medium through which the information is presented, the 
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computer. Computer-based information systems have a 
great number of differences from paper-based text and 
picture formats. The differences do not automatically 
favor the computer version. For instance, if a city planner 
is using a map of one resolution and decides that not 
enough area is covered by the map, two options are 
available: change the map scale or get a bigger sheet of 
paper. Computer users are limited by the maximum 
screen size that the system will support and therefore 
must change the map scale. The reduction in scale and 
the concomitant loss of information may be undesirable. 
Other computer-related difficulties arise with defining the 
language by which work is coaxed out of the computer 
and in determining ways to optimize data storage and 
access. 

Approach/Method 

Prototype and Evaluation of a GIS 
Implementation 

The strategy employed in the HCIL to increase 
NASA’s understanding of GIS interface and application 
issues involves three activities: literature review, 
experimentation, and iterative GIS design. Through 
review of the relevant literature, we have developed a 
broad understanding of issues, theories, and potential 
solutions regarding GIS interface design. Experimenta- 
tion allows us to test theories and solutions in a controlled 
setting. 

Iterative GIS design is an approach in which we learn 
by developing, testing, and redesigning a system. 
Specifically, we are working with the Space Shuttle Earth 
Observation Office at JSC on the implementation of a 
GIS to support the SSEOP. SSEOP provides support to 
Space Shuttle Earth-looking photography. SSEOP 
activities to be supported by the GIS include selecting and 
describing photographic targets, providing the Shuttle 
crew with photograph acquisition training, and 
cataloguing the mission photographs. 5 * 6 In order to meet 
these needs, the GIS development must go through the 
steps of task analysis, prototype development, system 
implementation, and user/system performance evaluation. 

The information gained from a task analysis of 
SSEOP tasks was incorporated in three GIS prototypes. 
The first prototype is geared toward supporting real-time 
photograph target selection for missions (fig. 1). The 
information is displayed in both pictorial and text format 
to aid the user in selecting optimal targets. Pictorial 
images of the Shuttle orbit are overlaid on variable scale 
world maps. Access is provided to data sets, including 
day/night cycles, previous photography, current world 
events, and incoming requests for photography. The 
prototype also includes a word processing form on which 
messages are prepared for delivery to the Shuttle crew. 

The second prototype addresses SSEOP’s cataloging 
and indexing (C&I) activities (fig. 2). A large part of the 
C&I task involves pattern recognition on the part of the 


SSEOP staff. The Earth observation photographs are 
examined and the photograph’s center point matched to 
map coordinates. The coordinates, as well as descriptive 
information about the photograph are then entered into the 
data base. The prototype provides access to existing data 
bases containing flight parameter information and surface 
pattern information in the form of maps and previous 
photographs. Functions for altering the map scale, 
orientation, and geometry aid in the pattern matching task. 

The third prototype incorporates training information 
prepared by SSEOP personnel in a mission specific 
tutorial for the Shuttle crew. Training information is 
grouped in four general areas. World maps with orbit 
track overlays, approach photos from the Shuttle, and an 
animated Earth horizon view are grouped in one screen to 
provide information about flight path and viewing 
perspective (fig. 3). Another screen provides text 
descriptions of preselected photography sites along with 
fly-over views and detailed geographical reference 
information. The third screen presents a timeline of fly- 
over times of preselected photography sites displayed 
side-by-side with the mission activity timeline. The final 
screen contains text descriptions of important geological, 
meteorological, and oceanographic features; techniques 
for photographing these features; fly-over information; 
and a selection of classic Shuttle photographs of the 
features. Initially, this tutorial package will provide 
needed preflight reference and pattern recognition 
materials to crewmembers and in the future could become 
an onboard package for new and refresher training. 

Results 

Summary of the Prototype 

The prototype GIS has undergone a number of 
reviews by the HCIL and SSEOP technical personnel. In 
keeping with the iterative approach, these reviews have 
resulted in improvements of the prototype. Having 
achieved broad approval for the concepts and functions 
demonstrated in the prototype GIS, we are currently in the 
process of developing the components of the working 
system. In that process, components will be 
implemented, usability testing conducted against a 
baseline measure of task performance, and revisions made 
to the GIS as warranted. 

Conclusions 

Preliminary Lessons Learned 

While they must be considered preliminary, some 
statements can be made regarding lessons learned from 
the GIS project. Perhaps the most basic lesson is that a 
GIS is conceptually little more than a data base and a 
graphical means of displaying selected data. It must be 
remembered that the magic associated with a GIS is not in 
the image quality of the display. If there is any magic, it 
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resides in the quality of the information entered into the 
system and the judicious understanding of information 
analysis and presentation on the part of the user. 7 As with 
statistical packages, the admonition “garbage in, garbage 
out” applies to the use of a G1S. 

The second lesson, following from the first, is that 
data bases are difficult to construct. The difficulty lies in 
the formalization of knowledge. When a data base is 
constructed for some land area, each sample point has a 
fixed set of characteristics associated with it. Data 
analysis and presentation is limited to these characteristics 
or to some combination of them. On the other hand, the 
human observer confronted with an on-the-spot analysis 
of the same area may introduce or discard, and combine 
or separate information in ways limited only by the 
capacities of the senses and immediate memory. This 
distinction is nothing new, nor is the study of what 
characteristics constitute true knowledge about objects. 
While the world of GIS implementation may not be 
expected to solve the problem, good GIS implementation 
will benefit from understanding the issues surrounding 
concept formation. Xiao and Raafat and Zhang and 
Giardino have demonstrated how thoughtful use of data 
structure can be used to verify and structure new data. 9,10 

The final lessons that have taken form at this point in 
the project relate to the focus in the GIS world on 
graphical, or more specifically, pictorial images. The 
emphasis is placed on the pictorial because GIS graphics 
rarely consist of bar graphs, pie charts, or x, y coordinate 
functions. The emphasis is placed squarely on pictures in 
color and with iconic representation of objects. The 
difficulties with graphic and pictorial displays are 
described in detail by Bertin, Tufte and Cleveland. 11 ’ 12 * 13 
While cartographers can provide extensive information on 
optimal map creation, the assumption that mapmaking is 
the exclusive benefit from GIS is misguided. 14,15 ’ 16 In the 
case of the proposed SSEOP GIS, most of the expected 
productivity gains are related to centralized access to 
information and implementation of needed data bases. 
Examples of innovative graphical techniques in GISs 
include Urban’s use of 3-dimensional data representations 
(not to be confused with 3-dimensional perspective 
pictures) and Welch’s use of stereographs to present 
elevation and distance data. 17 * 18 In general, the user who 
takes into account the breadth of information display 
techniques will be much more successful than those who 
fixates on pictures. 
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Figure 1. GIS Prototype for SSEOP Real-Time Photograph Target Selection. Windows Include Reference Map, Flight 
Note Form, and Data Bases, Including Previous Photographs, Geopolitical Information, and Outside Photograph Requests. 
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Figure 2. GIS Prototype for SSEOP Cataloging and Indexing. Windows Include Film/Mission Reference Information, 
Map Reference, World Reference, and Previous Photograph Data Bases. 



Figure 3. GIS Prototype for Crew Training. Windows Include Mission Orbital Paths as Represented on a World Map, 

3-Dimensional Globe and in Previous Earth Observation Photographs. 
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Abstract 

The space program is seeing an increased number of 
extravehicular activities (EVAs); thus, it is of interest to 
NASA to know the capabilities that astronauts have in 
performing their EVA tasks. Also of interest are the 
requirements on equipment used during the EVAs. Some 
EVAs do not allow for the use of foot restraint devices to 
hold the astronaut’s body in position; rather, handrails are 
used. This study documented the loads produced by 
subjects performing a tool task without the use of foot 
restraints. Six subjects, all wearing a Shuttle 
extravehicular mobility unit (EMU) space suit, 
participated in this study aboard an aircraft flying 
parabolic trajectories, which produces brief periods of 
weightlessness. The task was to perform a maximal effort 
with one hand holding a 25 cm wrench. The subject’s 
other hand grasped an EVA handrail. The torque on the 
wrench was measured, as well as the forces and moments 
transmitted to the handrail. Peak torques during the 
wrenching task were on the order of 70-80 Nm. Peak 
forces were on the order of 100 N normal to the surface 
and 200 N in a tangential direction. Greater torque and 
loads were produced when using the tool in a direction 
toward the midline of the subject’s body than were 
produced away from the midline. These results can be 
applied to the development of tasks and equipment for use 
during EVAs. 

Introduction 

Because of an increase in the number of EVAs that 
astronauts will be performing in the coming years, NASA 
is interested in determining the capabilities of a suited 
astronaut working in a weightless environment. 

Traditionally, an astronaut involved in EVA tasks is 
held in position by a portable foot restraint (PFR). The 
PFR provides adequate restraint to counter the forces 
generated from the use of a wide variety of powered and 
nonpowered EVA tools. In certain situations, it may be 
advantageous to perform operations while free floating. 
This would eliminate the need for a PFR setup. In those 
situations, the astronaut would have to grasp the EVA 
handrail in one hand and perform the task with the other. 

Some work has been done at NASA investigating the 
capabilities of suited astronauts to perform certain tasks 
while in foot restraints. However, very little information 
is available concerning their abilities to perform duties 
without the use of foot restraints. In addition, there is 
interest in gathering information concerning the loads 


transmitted to the EVA handrail when performing this 
type of task. 

Many of the tool tasks which astronauts are expected 
to perform can be classified as torquing tasks, in which 
they must use a wrench or similar tool to apply a torque to 
a fitting or fastener. 

This study was intended to examine the loads 
produced by a suited subject performing a torquing task 
with a single EVA handrail and no foot restraints. 
Specifically, the purposes of this investigation were to 

• Determine the amount of torque which can be produced 
by a suited subject in a weightless environment without 
the use of foot restraints 

• Measure the loads applied to the supporting hand while 
performing a torquing task in zero g without the use of 
foot restraints 

• Determine differences in the loads produced while 
performing a torquing task between individuals’ 
dominant and nondominant sides, and between different 
directions of tool rotation (clockwise versus 
counterclockwise) 

Methods 

Six male subjects participated in this study including 
four astronauts and two nonastronauts. All of them were 
experienced in performing tests while wearing pressurized 
suits. The subjects had each passed an Air Force Class III 
physical examination and had met the requirements for 
the physiological training program, as prescribed by 
NASA. Their heights ranged from 162 cm to 180 cm 
with a mean of 175 cm and their masses varied from 61 
kg to 77 kg with a mean of 70 kg. While all of them were 
right-handed, both hands were tested in the study. 

Tests were conducted aboard NASA’s KC-135 
aircraft. This is a modified jet which is capable of flying 
parabolic arcs, during which the passengers and 
equipment within the plane experience virtual zero g. 

Each parabola lasts approximately 25 s. 

Figure 1 depicts the work site arrangement. A 
unistrut framework, approximately 190 cm by 55 cm, was 
attached to the aircraft floor. An AMTI (Model #OR6-6- 
1000, Advanced Mechanical Testing, Inc., Newton, 
Massachusetts) force platform was placed at the center of 
the frame. An EVA handrail was bolted to the center of 
the force platform. On one side of the EVA handrail was 
a fixed 7/16 in bolt head, located 61 cm (24 in.) from the 
center of the forceplate. An instrumented torque wrench 
(Model #1150-200, GSE, Inc., Farmington Hills, 

Michigan) was used to measure the torque output. The 
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wrench had a padded handle located 24.8 cm (9.8 in.) 
from the tool end. 

Amplifiers (Model #2120A, Measurements Group, 
Raliegh, North Carolina) from the four tri-axial load cells 
in the force platform gave outputs of three orthogonal 
components of force and three orthogonal components of 
moments. The coordinate system of the forceplate was 
such that with the subject positioned as in figure 2, the 
Y-axis was parallel to the longitudinal axis of his body, 
the X-axis corresponded to the mediolateral axis of his 
body, and the Z-axis was perpendicular to the coronal 
plane of his body. The six force platform signals, along 
with the analog output from the instrumented torque 
wrench, were sampled digitally by a data acquisition 
system at a rate of 250 Hz. 

During the flight, prior to the start of the zero-g 
parabolic arcs, the subject donned the Shuttle EMU with 
the help of suit technicians. The suit was then pressurized 
to 4.3 psi. At the onset of zero g, the subject was assisted 
to the work site by two people where the torque wrench 
was attached to the fixed bolt fitting with the arm of the 
wrench parallel to the longitudinal axis of the subject’s 
body. The subject was instructed to produce as much 
torque in the wrench as he could, using the handle 24.8 
cm (9.8 in.) from the end. His other hand held onto the 
handle mounted on the force platform. He first rotated 
the torque wrench in one direction and held it there for 
several seconds; he then rotated the wrench in the 
opposite direction and held it there for several seconds. 
Forceplate and torque wrench data were collected during 
the zero-g interval. 

A repeated measures design was used in this study. 
The independent variables included the hands (dominant 
versus nondominant) and the directions in which the force 
was applied (inward versus outward rotation). Each 
subject performed two trials for each hand/direction 
combination. The dependent variables included the three 
axial components of force, the three components of the 
moment, the resultant shear force magnitude and 
direction, and the torque output from the wrench. 

Raw data were in the form of seven channels of time- 
based data for each parabola (three forces and three 
moments from the forceplate, and the torque from the 
torque wrench) for the duration of the zero-g interval. 

The window of data corresponding to the actual 
performance of the task was determined from plots of the 
data and from the video recordings. Within each window, 
the peak magnitude for each of the seven channels was 
obtained. The two components of force parallel to the 
direction of movement (X and Y) were combined to 
calculate a resultant shear force magnitude and direction. 
Thus, there were a total of nine dependent variables. For 
comparison purposes, necessary manipulation of the data 
was performed in order to change the coordinate system 
from one based on the forceplate to one based on the 
subject. 

From the two trials for each conditions, the larger 
value for each of the nine dependent variables was taken 


as representative for that subject. Statistical analyses 
focused on eliciting the differences between the dominant 
and nondominant hand (left versus right) as well as 
between different directions of movement. The responses 
of each dependent variable to the test variables (hand 
dominance, direction) were first examined descriptively. 
Next, the dependent variables were tested for statistical 
significance using various statistical tests. A multivariate 
analysis of variance (MANOVA) was performed to 
determine the collective response of the dependent data to 
changes in each one of the test variables. Each 
MANOVA was followed by an univariate analysis of 
variance (ANOVA) to determine the influence of all test 
variables and their interactions. Finally, the Ryan-Einot- 
Gabriel-Welsh test criterion was used to determine 
whether there were significant variations within the levels 
of each test variable. A significance level of 0.05 was 
chosen to determine whether the analyses were significant 
or not. 

Results/Discussion 

Table 1 below presents the group results from the 
experiment. The column labels indicate the test 
conditions: side and direction of rotation. “Left” and 
“Right” indicate the arm that was used to generate the 
torque with the wrench. Recall that all subjects were 
right-dominant. “In” and “Out” indicate the direction of 
rotation, relative to the midline of the subject’s body. An 
inward movement with the right arm was a clockwise 
rotation; outward was counterclockwise. Similarly, an 
inward movement with the left arm was a 
counterclockwise rotation; outward was clockwise. 

The first row presents the maximum applied torque 
(in Newton-meters) from the tests as measured by the 
instrumented torque wrench. The remaining data are 
from the forceplate connected to the handrail. 

Statistical analysis of the data revealed that there was 
no significant difference between using the left and right 
hands. However, the two directions of rotation were 
significantly different in the measures of: X force, X 
moment, Z moment, torque output, and the resultant shear 
force. All of these variables were found to be 
significantly greater during inward motion than during 
outward motion. With regard to the Y force and moment 
and the Z force, there were no significant differences 
between the inward and outward directions. 

The greatest component forces were in the X 
direction along the mediolateral axes of the subjects’ 
bodies. This was expected since the X axis was the axis 
along which the force was applied to the wrench. 
Magnitudes of the X component of force were 
approximately 171 N for outward rotations and 223 N for 
inward rotations. The peak components of force in the Y 
and Z directions were relatively low and fairly consistent 
across the test conditions. The peak Y force, which was 
parallel to the operator longitudinally, ranged between 68 
and 111. The peak Z force averaged around 68 N. 
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As expected, the greatest moment occurred around 
the Z axis (30 Nm) and the lowest moment occurred 
around the X axis (9 Nm). The peak Y moment remained 
fairly constant around 18 Nm. The peak X and Z 
moments were significantly affected by the direction of 
rotation. On an average, the peak X moment dropped 
from 16.7 Nm to 9.9 Nm when the direction changed 
from inward to outward rotation (decrease of 41%); the 
peak Z moment dropped from 29.2 Nm to 14.6 Nm 
(50%). The shear force was also significantly higher 
during inward rotation than during outward rotation. The 
shear force averaged about 226 N and 169 N during 
inward and outward rotations, respectively (decrease of 
25%). Finally, the maximum amount of torque was about 
72 -m during inward rotation and about 46 Nm during 
outward rotation. 

Conclusions 

In summary, suited operators performing a wrenching 
task in a weightless environment without the use of foot 
restraints generated approximately 72 Nm of torque. 
During this task, the loads transmitted by the other hand 


to the supporting structure were approximately 78 N in a 
normal direction and 226 N in a tangential direction. 
Torques and loads were significantly less when pulling 
the wrench inwards than pushing outwards. These results 
can be applied to the development of tasks and equipment 
for use during EVAs. 

In summary, suited operators performing a wrenching 
task in a weightless environment without the use of foot 
restraints generated approximately 72 Nm of torque. 
During this task, the loads transmitted by the other hand 
to the supporting structure were approximately 78 N in a 
normal direction and 226 N in a tangential direction. 
Torques and loads were significantly less when pulling 
the wrench inwards than pushing outwards. These results 
can be applied to the development of tasks and equipment 
for use during EVAs. 
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Table 1. Averaged Subject Data for the Torquing Experiment. Force Values are in Newtons; Moments and Torques are in 
Newton-Meters. Standard Deviations are Given within the Parenthesis. Values are the Average of the Six 

Subjects’ Greatest Efforts. 


VARIABLE 

LEFT 

jJX 

LEFT 

-OUT 

RIQHT-1N 

RIGHT 

-OUT 

Peak Torque 

67.4 

(10.0) 

42.5 

(13.0) 

75.6 

(18.3) 

48.8 

(22.1) 

Peak Force X 

209.8 

(19.3) 

170.2 

(72.7) 

236.1 

(26.5) 

172.3 

(67.1) 

Peak Force Y 

110.7 

(20.4) 

98.5 

(42.6) 

90.0 

(35.3) 

68.2 

(31.5) 

Peak Force Z 

90.4 

(57.6) 

51.2 

(13.8) 

65.7 

(45.7) 

65.8 

(38.9) 

Peak Shear Force 

212.4 

(16.4) 

164.7 

(78.0) 

240.1 

(24.8) 

173.9 

(66.8) 

Angle at Peak Shear 

19.4 

(4.1) 

22.6 

(7.3) 

11.9 

(4.5) 

9.4 

(12.3) 

Peak Moment X 

18.2 

(5.4) 

8.8 

(2.5) 

15.1 

(3.0) 

10.9 

(6.5) 

Peak Moment Y 

17.0 

(1.9) 

16.4 

(8.3) 

20.5 

(2.0) 

18.8 

(11.8) 

Peak Moment Z 

29.7 

(4.1) 

15.0 

(8.1) 

28.7 

(6.3) 

14.2 

(6.7) 
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Figure 3. Picture of Subject Performing Torquing Task. 
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Tunable Plasma Rockets with RF-Heating and Superconducting Thrust Chambers 
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Abstract 

Theoretical and experimental research in tunable 
plasma propulsion (variable specific impulse/thrust at 
constant power) has been carried out over the last decade. 
Important developments of this research include: the 
demonstration of an increased radio frequency (RF)-to- 
plasma coupling efficiency (68%) as a result of antenna 
design and relocation, as well as wave launching 
techniques; the theoretical demonstration of plasma-field 
detachment at the rocket exhaust; and the experimental 
validation of predicted performance parameters. Other 
results include the estimation of attractive power specific 
mass or “alpha” values of 8 kg/kW, including the power 
system, and the use of off-the-shelf components. 
Substantial improvements to these values are expected 
with emerging technologies in high-temperature 
superconductivity and RF-confinement. 

Introduction 

One of the most important issues in connection with 
human interplanetary travel is the crew’s prolonged 
exposure to weightlessness as well as the high radiation 
dosage that accrues during long voyages. From this point 
of view, it becomes crucial to achieve a minimum trip- 
time and to extend the ship’s acceleration schedule 
consistently with human and power plant limitations. 
Flexibility in these well-known “trajectory variables,” 
however, remains limited by the capabilities of 
conventional (constant specific impulse (1^)) chemical 
engines. Trip-times remain “high” and are severely 
restricted by payload and fuel constraints while 
acceleration time is negligibly short compared to total 
trip-time. Intensive research in the development of higher 
power and I electric and thermal rockets (including 
nuclear rockets) has ameliorated the payload-to-fuel 
limitation while somewhat reducing the trip-time. These 
advances have also prompted this present reexamination 
of variable propulsive “schedules” in the operation of 
“power-limited” rockets; these advances promise still 
better performance, with extended beneficial acceleration 
profiles and consequent reductions in trip-time. 

Problem Statement 

It is well known that, when a rocket engine is limited 
by power, the attainment of high I does not necessarily 


comes only at the expense of thrust. While the fuel 
requirement to achieve the trip may be drastically reduced 
over a low 1^ case, the trip-time rapidly increases. 
Actually, for a power-limited rocket, the best compromise 
between thrust and I is one where the two quantities are 
allowed to vary and be continuously “tuned” to the 
conditions of flight; such is the case in the present 
approach. 

In a typical case, the rocket starts from orbit around 
the planet of origin at a high thrust/low 1^. As the vehicle 
moves away from the gravity well, I increases while 
thrust decreases at constant power. At some intermediate 
point, the profile reverses and the rocket decelerates, 
under power, and is captured by the destination planet. 
Optimum I variations can be very high (tens of 
thousands of seconds), depending on the particular 
mission. If these conditions are achieved, trip-times on 
the order of 3 months can be achieved for missions to 
Mars. Additionally, optimization of the acceleration 
profile leads to gains in payload fraction over the 
conventional chemical or nuclear thermal rocket. These 
results (Irving and Blum 1 ) are reproduced in figure 1. 

New Technologies 

Hitherto unattainable exhaust properties are now 
possible with the advent of new technologies in plasma 
heating and containment that were developed for the 
Controlled Thermonuclear Fusion Program. Moreover, 
recent developments in high-temperature 
superconductivity have pushed these embryonic concepts 
even further into the realm of engineering design and field 
test. 2 

To this end, over the past decade our group has been 
engaged in the development of a variable 1^, RF-heated 
electrothermal rocket based on the technology of tandem 
mirrors. 3 The particular approach considered here, 
because it is not a fusion concept, has permitted a 
substantial relaxation in the physics requirements on 
plasma density and temperature as compared with its 
fusion counterpart. In fact, the tandem mirror — an open- 
ended linear device that suffers from end-loss limitations 
in fusion — becomes particularly well suited as a variable 
I rocket by virtue of such innate “leakage.” Moreover, 
experiments performed in the closing years of the U.S. 
mirror program revealed an intrinsic axial asymmetry and 
plasma flow in these devices that we have sought to 
exploit. 
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Approach 

In the present system (shown schematically in figure 
2), thrust is produced in a three-stage process of: (1) cold 
plasma injection at high density, (2) high power 
amplification via ion cyclotron resonance heating, and 
(3) plasma expansion and magnetic field detachment in a 
two-stage hybrid (magnetic/conventional) nozzle. The 
magnetic system itself is an asymmetric, superconducting 
derivative of the tandem mirror but with greatly relaxed 
technical requirements over those of its predecessor (i.e., 
being able to confine plasmas radially that are not 
thermonuclear in nature) and, hence, is completely 
attainable with present technology. This particular 
configuration offers several advantages over more 
conventional plasma propulsion schemes; among these 
are: 

• Variable thrust and I at constant jet power: allows 
continuous exhaust optimization over the entire 
mission. This reduces the transit time for a given fuel/ 
payload allocation over that obtainable with a constant 
I at the same power. 

• Electrodeless design: Relaxes many of the material 
constraints imposed on plasma devices where the fluid 
is heated or accelerated by means of physical electrodes 
that are immersed in the hot plasma. This relaxation, in 
turn, allows a greater power density. 

• Magnetic and gas-dynamic insulation: Also relaxes 
materials requirements on the first wall of the thruster 
and is consistent with very high (> 1 kW/cm 3 ) power 
densities. In addition, the established hypersonic 
coaxial gas layer provides a mechanism for collisional 
detachment of the plasma flow from the guiding 
magnetic field at the exhaust. 

Results 

One of the main experimental results has been the 
demonstration of a high RF-to-plasma coupling efficiency 
(68%). This efficiency is a result of relocating the main 
antenna to a point at the inboard side of the central cell 
magnetic mirror. This location allows the RF wave to 
undergo maximum damping as the wave travels to the 
center of the device. The effect, which is called Beach 
heating, was theoretically predicted and experimentally 
confirmed in our laboratory. 4 These results are shown in 
figure 3. 

In terms of the dynamics of plasma exhaust, 
extensive theoretical and numerical work has been carried 
out. 5 Studies show that the presence of a well-established 
coaxial, hypersonic, neutral boundary layer can induce the 
plasma to detach from the guiding magnetic field. 
Detachment efficiency is expected to be a function of the 
“pitch angle” of the neutral jet with respect to the main 
plasma flow. Numerical plume dynamics for three cases 
are shown in figure 4: (1) free plasma expansion along 
the field with no gas injection; (2) plasma flow that is 
limited by the presence of purely axial gas flow; and 


(3) plasma flow that is limited by the injection of a radial 
jet. A modification of the third option will be used during 
experimental verification. 

Additional laboratory experiments are also providing 
data on the operating characteristics of this device. These 
data fit very well with predicted performance curves. For 
example, a low-density, low-power (9.4 kW) case study is 
shown in figure 5 for hydrogen at 68% efficiency; the 
three discrete points are experimental values. Additional 
measurements at higher densities and lower temperatures 
need to be carried out to validate fully the predicted 
performance envelope. The rocket performance envelope 
scales linearly with power; hence, thrust values of 
thousands of Newtons are obtainable for the 
multimegawatt systems proposed for Mars. 

Careful engineering studies and implementation of 
new technologies in magnetic vectoring and expansion 
nozzles have demonstrated that these systems can be 
made competitive in terms of their power specific mass or 
“alpha.” Values of 8 kg/kW or less, including the nuclear 
power system, can be predicted. 6 Additionally, new 
developments in monolithic superconducting systems and 
in the use of high voltage and regenerative liquid 
hydrogen designs may reduce this value further. 7,8 

Finally, two emerging technologies are also being 
examined for potential application to this system: high- 
temperature superconductivity and RF-plasma 
confinement. New developments in these areas would 
strongly influence the success of this rocket. For 
example, the use of newly developed monolithic 
“magnetic replicas” to trap intense (> 2tesla) static 
magnetic fields are being explored, because they would 
greatly simplify the superconducting coil design and 
further reduce the total weight. Our group is also 
investigating the use of RF energy-not just to heat the 
plasma, but to introduce additional radial confinement 
with consequent increases in the available plasma 
pressure. This is a collaborative effort led by Drs. Roger 
Remy and Jean Luc Cambier of ACC Inc., Dr. Steven 
Howe of the Los Alamos National Laboratory, and 
technical personnel from the Phillips Laboratory and the 
University of New Mexico. 

Conclusions 

Ongoing research in this new propulsion technology 
has produced several advances that open the path for a 
flight demonstration experiment. First, experimental 
results of RF-to-plasma power coupling show a much 
greater plasma power coupling efficiency than was 
previously estimated (68% vis-a-vis 55%). This is a 
result of refinements in the theory of RF plasma heating 
as well as in modifications in antenna positioning within 
the magnetic chamber. Second, engineering estimates of 
specific power or “alpha” of the system point to an 
attractive scaling at 8 kg/kW, of which the thrust system 
represents a negligible fraction. These conservative 
estimates, which use off-the-shelf equipment, may be 
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further improved for longer systems through the use of 
new technologies in superconductivity and RF 
confinement as well as through th'e use of power at high 
voltage. Finally, experimental measurements of plasma 
properties at high I follow the predicted values. 

Despite these advances, further experiments need to 
be performed to validate the theory at lower I . Also, 
measurements need to be carried out that are designed to 
demonstrate the successful detachment of plasma from 
the guiding magnetic field at the exhaust. These 
experiments are being planned at this time. 
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Abstract 

The program described in this report was initiated to 
develop a prototype power tool to replace the unit now in 
the National Space Transportation System (NSTS) 
Program. The unit developed under this program is a 
hand-held, battery-powered unit that has simultaneous 
torque and revolution controls. A digital readout provides 
a visual indication to the operator regarding desired 
torque/number of revolutions that the unit is set to provide 
and actual torque/number of revolutions produced. 

Torque accuracies of 10% over the full range of 10 to 
200 in-lbs were obtained. The unit uses a strain gauge 
system to measure the actual torque output and provides a 
feedback to a magnetic particle clutch to limit the torque 
produced from the motor. 

Introduction 

A significant number of tasks performed by an 
extravehicular activity (EVA) crewmember during the 
maintenance and repair of a payload or satellite require 
the removal of various types of threaded fasteners. A 
crewmember fatigues rapidly while performing these 
multi-rotational tasks in the Weightless Environment 
Training Facility. During Shuttle mission Space 
Transportation System (STS)-41B, a power tool was 
developed to demonstrate its usefulness in performing the 
types of tasks that were required for STS-41C, the Solar 
Max Mission. This tool was used again during the 
WESTAR/PLAPA retrieval mission (STS-51 A) and the 
LESAT repair mission (STS-51 1). 

The tool that was selected for these missions was a 
commercial tool. The unit was a reversible, two speed 
(50/100 revolutions per minute (RPM)) with five 
selectable torque ranges. Modifications were made to the 
brushed direct current motor to make it compatible with 
the vacuum environment in which it was to operate. An 
additional gear system has been added to the tool to 
decrease the speed of the motor to 20/50 rpm and raise the 
torque output for use during the Hubble Space Telescope 
maintenance and repair mission. 

The major problem with this tool has been 
maintaining the tolerances on the torque settings between 
uses. This tool uses a slip clutch comprised of a spring, 
two plates, and a quantity of small ball bearings to 
regulating the torque output. Because of wear and 
temperature variations during the mission, it has been 
necessary to perform calibration tests at temperature 
extremes on the tools prior to their use on a mission. 


Other tools have been developed that use a feedback 
circuit to limit the current to the motor when the proper 
torque is reached. Owing to efficiencies of the gears and 
inertia of the overall system, units of this type are 
susceptible to overshoot of the desired torque. 

Problem Statement 

The problem is to develop a self-contained, hand- 
held power tool that can be operated in an EVA 
environment. The tool will have a range of 10 to 200 in- 
lbs with an accuracy of ±5%. Also, the tool will be 
capable of being set by the EVA crewmember and will 
provide a visual indication of the set/actual torque and 
number of revolutions. After the desired torque is 
reached, the tool will be programmed to provide a gradual 
release of the torque. 

Approach/Method 

The program established for the development of the 
power tool was separated into two phases. First, a brass 
board was to be developed to determine if a system could 
be assembled that would provide the desired torque 
accuracy and tolerance and would verify the program 
necessary to provide feedback to the components. We 
reasoned that a high level of accuracy could be obtained 
by the system with the use of a magnetic particle clutch. 
Based on the accuracy of the sensing device, the clutch 
could limit the amount of output torque by limiting the 
current to the clutch. A “ramp-down” feature could also 
be programmed into the unit that would provide a residual 
torque until the motor is shut off. 

Catalog searches were made to select the major 
components for the brass board. Selection of components 
was based on the requirement that the components could 
be used in the prototype power tool as is or with only 
minor modifications made to the prototype power tool. 
Preliminary software algorithms and integrated circuits 
were developed while awaiting receipt of the hardware 
components from the suppliers. A block diagram of the 
system is shown in figure 1. The brass board was 
assembled and demonstrated. A 2% accuracy was 
obtained for the full range of 10 to 200 in-lbs. 

Verification of accuracy was made using a calibrated 
torque meter on the output of the shaft. 

The second phase of the program was to design and 
manufacture a hand-held, self-contained unit that would 
be used for demonstration purposes. The unit was to be 
capable of selecting either the torque/revolution and the 
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level set by the operator. An indication of the levels set/ 
actual was also to be visible to the operator. 

A packaging design was initiated based on the 
utilization of components from the brass board. The 
layout assembly giving dimensions of the unit is shown in 
figure 2. The original plan was to have the electronic 
package separated from the power tool, and circuit boards 
were designed based on that requirement. We decided to 
integrate the electronics into the tool after the boards were 
completed This configuration would present a greater 
fidelity to the design of the final flight item. 

The final assembly was completed and demonstrated. 
Owing to manufacturing problems with the torque sensor, 
torque accuracies of 10% over the range of 10 to 200 in- 
lbs were obtained. The “as-built” power tool is shown in 
Figures 3 and 4. 

Results 

Based on tests performed with the brass board and 
the demonstration unit, a power tool can be manufactured 
that uses a magnetic particle clutch to provide a high 
degree of accuracy over a range of 10 to 200 in-lbs. The 
power tool is capable of adjusting “real time” in 5 in-lb 
increments and of providing visual indications of set/ 
actual levels of both torque and number of revolutions. 

Conclusions 

Designs of a proto-flight power tool are to be 
prepared and a tool manufactured that can be used in an 


orbital environment. In accordance with the NSTS 
requirement for Government-furnished equipment 
hardware ground testing, additional testing will be 
performed on the proto-flight power tool to verify its 
operational characteristics at temperature extremes and in 
a vacuum environment. After testing is completed, the 
proto-flight power tool would be used as part of an EVA 
flight experiment. 
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Figure 3. The “As-Built” Power Tool. 



Figure 4. The “As-Built” Power Tool. 


Space Systems Technology 


12 




EMU Fuel Cell and Metal Hydride Hydrogen Storage System 
In-House Evaluation 

Jose A. Marmolejo 
Johnson Space Center/EC5 


Abstract 

In this paper, we will give an update on recent testing 
of an advanced development effort carried out on an 
extravehicular mobility unit (EMU) fuel cell energy 
storage system that was initially developed for the Space 
Station Freedom (SSF) EMU. This concept, which is 
fueled by oxygen and hydride-stored hydrogen, is being 
considered as an alternative to the Shuttle EMU’s zinc- 
silver oxide battery. The main consideration drivers in 
choosing a newer technology are superior cycle life and 
quick recharge. Our test article was comprised of selected 
test points from an earlier test series. This test article was 
retested to identify any discrepancies resulting from a 
period of nonuse that may exist with this technology 
(such as limited life). 

Introduction/Background 

The limitations of the zinc-silver oxide battery that is 
currently used in the Space Shuttle EMU are a serious 
concern for SSF, where a much greater number of 
extravehicular activities (EVAs) will be required. (It is 
anticipated that EVA pairs will be performed from the 
Station up to 52 times a year.) In the Shuttle Program this 
battery technology has demonstrated a short wet-life 
(120 days), a limited cycle life (only 8 cycles), and a slow 
recharge time (> 20 hours). Its usage would be 
impractical on SSF because of cost, volume, logistics, 
logistics bookkeeping, crew interface for servicing/ 
replacement, and storage. Unfortunately, the mature 
technology of the zinc-silver oxide battery does not offer 
much potential for improvement. 

On the other hand, the oxygen-breathing proton 
exchange membrane fuel cell that is fueled by hydride- 
stored hydrogen presents an attractive alternative to the 
zinc-silver oxide battery for Space Station or for other 
program applications. It has the potential of matching the 
operational simplicity of the battery while overcoming its 
shortcomings in performance. Even at this early stage of 
development, an attractive performance future can be 
projected for this technology. The goal of the NASA 
development program was to demonstrate the fuel cell/ 
hydride technology pair as an alternative EMU power 
supply by meeting the following objectives: high energy/ 
volumetric density (comparable to that or smaller than 
that of batteries), high cycle capability (> 500 cycles), 
quick recharge capability (< 25 minutes), and safety (with 
hydrogen stored within metal hydrides). 


Fuel Cell Energy Storage System (FCESS) 
Design 

The FCESS is comprised of a 32-cell proton 
exchange membrane stack, a metal hydride storage vessel, 
and a control subsystem. The cell stack design features 
passive water removal, thermal and physical integration 
with the hydride vessel, and waste heat removal by means 
of the EMU water-cooling system. The metal hydride 
storage vessel contains enough hydrogen to fuel the 
FCESS for up to 5 hours. Although metal hydrides have 
demonstrated a hydrogen storage ability that is superior to 
liquification, a metal hydride is being used in the EMU 
application primarily for safety reasons. The control 
subsystem provides reactant pressure and flow regulation, 
automatic start-up and shutdown, and electronic circuitry 
for protection of the power source against malfunctioning. 
A functional schematic of the FCESS breadboard unit is 
shown in figure 1. A fuel cell with thermally linked metal 
hydride hydrogen storage cylinders is shown in figure 2. 

The FCESS, which was designed and fabricated 
under NASA Contract NAS 9-17775, is a freestanding 
power source that is suitable for bench testing at 
atmospheric pressure (fig. 1). Under a previous test 
series, it was shown that the FCESS design surpassed 
contractual statement of work (SOW) requirements in 
several areas. Noteworthy are a significantly lower 
volume, a faster recharge, and a substantially longer 
projected cycle life. Design specifications and 
operational features are summarized in tables 1 and 2. 
SOW requirements, where applicable, appear in brackets. 

Previous Testing 

Prior to NASA delivery, baseline and acceptance 
tests were performed at the vendor to verify performance 
of the FCESS design. A total of 78 test hours were 
logged, including numerous FCESS start-ups and 
shutdowns that were intentionally induced to check out 
the protective circuitry, and loads were induced that 
ranged from 4.5 to 15.7 amperes. Results of the tests 
have confirmed proper electrical performance, rated 
capacity, good thermal efficiency, adequate hydride 
performance, and no operational purge requirements (as 
predicted). 

Upon NASA delivery, an additional 197 hours of 
operation over 38 cycles, including regenerations, were 
performed on the FCESS unit during September 1989 and 
January 1990. At that time, the unit had met or surpassed 
all SOW requirements. 
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Latest Testing 

Approach. The objective of the latest test series 
was to revisit selected test points from the earlier NASA 
test series to evaluate any discrepancies resulting from a 
period of non-use that may exist with this technology 
(such as limited life). It was expected that degraded cell 
voltages (and total stack voltage) would be observed as 
well as a degraded water collection capability that is 
primarily owing to the FCESS not being operated in 
nearly 2 years. 

The approach was to test the FCESS in an ambient 
environment over a range of operational test conditions 
including: a current demand of 7 amps, and coolant flow 
rates to maintain the stack temperature between 140°F 
and 158°F with coolant temperatures maintained between 
50°F and 80°F. Regeneration test conditions included: 
coolant flow rates of 240 lbs/hr with coolant temperatures 
maintained between 45°F and 75°F and a hydrogen 
supply feed pressure of 250 pounds per square inch gauge 
(psig). 

Results. A power functional test of the FCESS was 
held the day after a standard hydrogen recharge. During 
the functional test, an open circuit voltage of 30 volts was 
measured as expected (28 ± 4 volts). When a minimum 
load of 3 amps was applied, however, the stack voltage 
dropped to 12.2 volts. The only plausible explanation for 
the poor performance of the FCESS was that the fuel cell 
stack had become dehydrated during storage. A 
procedure was implemented that consisted of applying a 
minimum load for 30 seconds followed immediately by 
the application of no load (0 amps). By the end of the 
functional test, the FCESS was providing 24.7 volts at 
7 amps. Although the FCESS was run for a period of 


nearly 5 hours, only 50 cc of water were produced, which 
supported the theory that the fuel cell stack was 
dehydrated. Nonetheless, operation was within item 
specifications. 

Two additional recharge and discharge cycles were 
performed on the FCESS. Voltages of 24.6 volts at 
7 amps over 5:01 hours and 25.8 volts at 7 amps over 
5:10 hours were recorded, respectively, for those 2 test 
days. In addition, a water production of 360 cc and 
350 cc, respectively, was also measured and was as 
expected. 

Conclusion/Summary 

Since delivery of the FCESS in April 1989, numerous 
test hours over numerous charge and discharge cycles 
have been recorded by NASA on the FCESS, thus 
proving the viability of this technology as an alternative 
to the zinc silver-oxide battery technology currently in use 
by NASA. During the latest test series, it was shown that 
the FCESS could operate within its design specifications 
even after being stored for a period of nearly 2 years. 

This last exercise also demonstrated a procedure for 
“rewetting” the fuel cell stack that may be experienced 
during this storage time period, thus allowing the system 
to become activated safely and to operate well within its 
design specifications. 
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Table 1. FCESS Design Specifications 


Capacity: 

Voltage: 

Current rating: 
Ambient temperature: 
Volume(l): 

Weight: 

Hydrogen storage: 
Oxygen storage: 
Product water: 

Venting of gases: 

Heat release: 

Cycle life: 

Charge time: 

(l)Exclusive of controls 


34 A-hrs ( app. lOOOW-hrs) 
28 + 4 volts 

7A 

122°F 

415 in^ [<1000 in*] 

35 lbs 

Metal hydride 
Compressed gas 
Potable, zero-g removable 
None, start-up purge only 
<200 British thermal unit 
(Btu)/hr [<300 Btu/hr] 

5000 [>120] 

<15 minutes [30 minutes] 


Table 2. FCESS Operational Features 

• No venting of gases; start-up purge only 

• Dead-end reactant flow regulation 

• Product water removal by pressure-enhanced 
wicking 

• Passive waste heat removal 

• In-place hydride recharge 

• Start-up and regeneration by multiple purge 
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Figure 1. FCESS Integrated Test Article and Instrumentation Schematic. 
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Metal Oxide CO, and Humidity Remover 

Gretchen Thomas 
Johnson Space Center/EC 


Abstract 

The metal oxide C0 2 and humidity remover 
(MOCHR) is an advanced life support technology that 
will provide atmospheric control for an advanced 
extravehicular mobility unit (AEMU). The system was 
developed by the AiResearch Los Angeles Division of 
Allied-Signal Aerospace Company, and uses a bed of 
silver/zinc oxide pellets to absorb C0 2 and H 2 0 vapor. 
The MOCHR is regenerate by blowing hot air through 
the canister at ambient pressure. Testing was performed 
at JSC to demonstrate MOCHR performance over a 
period of time while it was being cycled between 
extravehicular activity (EVA) and regeneration modes 
and to assess system performance characteristics under 
nominal and off-nominal metabolic C0 2 and H 2 0 loads. 

In this report we will briefly describe the MOCHR system 
and summarize the results of the testing conducted by the 
Crew and Thermal Systems Division at JSC. Testing was 
performed in the EVA test-bed portable life support 
subsystem breadboard (PLSSBB), located in building 7, 
room 2007, from April 29 to July 21, 1992. 

Introduction 

The MOCHR was developed by the AiResearch Los 
Angeles Division of Allied-Signal Aerospace Company 
and is a candidate C0 2 and humidity removal subsystem 
for an AEMU. This technology uses a bed of silver/zinc 
oxide pellets to absorb CX> 2 and H 2 0 vapor. The MOCHR 
is regenerable by blowing hot air through the canister at 
ambient pressure. In actual use, absorption would take 
place in the extravehicular mobility unit (EMU) while on 
an EVA and regeneration would be performed in the 
airlock. 

Hie MOCHR was tested using a simulated PLSSBB 
design. The integrated system is designed to provide 
different metabolic rates by applying corresponding heat 
loads to the metabolic heaters in both vent and coolant 
loops, as well as by injecting the appropriate amount of 
C0 2 and H 2 0 vapor into the simulated vent loop. C0 2 
and HjO injection rates for each metabolic rate were 
determined using an array of past Shuttle EMU/ 
crewmember test and analysis results. MOCHR inlet vent 
loop temperature, humidity, and C0 2 concentration were 
varied correspondingly with the respective metabolic rate. 
The MOCHR was tested over a range of fixed and 
variable metabolic profiles. 

The MOCHR regeneration phase required 
transferring the test article from the absorption test stand 


to the regeneration unit. The regeneration unit was 
provided by the vendor and is located in building 7, room 
2007, adjacent to the PLSSBB test stand. The MOCHR 
was then regenerated by blowing hot air through the 
canister at ambient pressure following the vendor- 
supplied regeneration profile. 

Description 

The MOCHR consists of a bed of pellets made up of 
a matrix of silver-zinc oxide. Each of these pellets is 
approximately 1/16 in. in diameter, with an aspect ratio of 
1 to 1.5. Through absorption of C0 2 and H 2 0 vapor, the 
resulting reacted compounds consist of metal carbonates 
and bicarbonates, metal hydroxides, hydrates, and 
complex compounds. The absorption process is 
exothermic and the MOCHR uses an active cooling loop 
to carry off waste heat and to facilitate water vapor 
absorption. The MOCHR test article is shown in figure 1. 
As illustrated, the overall dimensions of the canister are 
approximately 15.4 in. X 12.0 in. X 4.7 in., giving the 
subsystem an overall volume of approximately 868.6 in 3 
(0.5 ft 3 ). Once the MOCHR completed an EVA mode 
operational test run, it was disconnected and placed on the 
vendor-supplied regeneration test stand. 

Approach/Method 

The test series was conducted in the EVA test bed 
PLSSBB, located in building 7, room 2007. This lab is 
maintained and operated by EC4, the Systems Test 
Branch of the Crew and Thermal Systems Division. 

Vent loop pressure was maintained at 8.3 psia during 
testing. The composition of the vent loop was initially 
standard breathing air — 20.5% oxygen (Oj) and 79.5% 
nitrogen (N 2 ) gas. A bubbler was used for water vapor 
addition, while C0 2 injection was supplied by a K-bottle. 
Because the MOCHR pellets cannot tolerate liquid water, 
the inlet dew point was always held a minimum of 2°F 
above the cooling water temperature to prevent 
condensation in the canister. 

Regeneration of the MOCHR takes place in two 
distinct phases. In the first phase, laboratory room air is 
heated to 190°F and is circulated through the MOCHR 
canister in an open loop mode to drive off the absorbed 
water vapor. In the second phase, air temperature is 
ramped up until it reaches 525°F. Again, the air is 
circulated in an open loop through the canister to drive off 
absorbed C0 2 . Upon completion of regeneration, the 
canister can either be actively cooled, closed loop, or 


17 


Space Systems Technology 



allowed to cool passively. The total regeneration process 
takes approximately 13 to 16 hours, with 9.5 hours for 
regeneration and 3 to 6 hours for cool down (passively 
cooled). 

Contract design provisions required that the MOCHR 
be able to absorb adequately metabolic C0 2 and H 2 0 
vapor corresponding to a 1000 British thermal unit (Btu)/ 
hr mixture ratio (MR) (0.2 and 0.3 lbm/hr, respectively) 
for 6 hours, plus a 500 Btu/hr MR (0.1 and 0.18 lbm/hr, 
respectively) for 2 hours for a minimum of 40 cycles, 
while maintaining a vent loop pressure drop less than or 
equal to 1.0 in H z O. This canister was delivered to JSC 
by the vendor after the vendor performed 5 cycles. These 
cycles were taken into account when evaluating the 
performance. All absorption test points were run to either 
C0 2 (7.6 mm Hg) or to H 2 0 (60°F dew point) 
breakthrough, whichever occurred first. 

Results 

The MOCHR completed a total of 40 EVA/ 
regeneration cycles. Five of these were at AiResearch 
and 35 were at JSC. 

Throughout the course of testing, the gas flow 
pressure drop through the canister increased from 0.7 to 
5.5 in H 2 0. This pressure drop is significantly higher than 
that called for in the specification of less than or equal to 
1.0 in H 2 0. 

Good C0 2 removal was demonstrated, and the over- 
design for C0 2 capacity was evident early in the test series 
when C0 2 absorption quantities significantly exceeded the 
1.4 lbm specification. The maximum C0 2 capacity of the 
MOCHR observed over all test points was -2.33 lbm. 
Although the capacity for the final test points was only 
1.48 lbm, which is a 36% reduction from the maximum, it 
was still above the requirement. Elapsed time to C0 2 
breakthrough and C0 2 absorption capacity both decreased 
-2% per test cycle. 

The maximum H 2 0 absorption capacity of the 
MOCHR, as observed in one of the early cycles, is -2.12 
lbm. This value meets the 2.1 lbm requirement. The 
capacity at cycle 38, however, was only 1.08 lbm, a 49% 
reduction from the maximum and also 49% below the 
requirement. The H 2 0 removal capacity specification 
(2.1 lbm) was met or exceeded in only one test point (2.12 
lbm in cycle 14). Cycles 12, 16, and 18 achieved 
quantities of 2.05, 2.02, and 2.02 lbm, respectively. 
Elapsed time to H 2 0 breakthrough decreased 1 to 1.5 
percent per test cycle. Water absorption capacity to 
breakthrough decreased -2% per test cycle. 

Conclusions 

The MOCHR unit has demonstrated the capability for 
concurrent C0 2 and H 2 0 removal for 40 absorption/ 
desorption cycles (35 of which occurred at JSC). The 


MOCHR performed equally well under a variety of 
steady-state and transient metabolic load conditions. 
However, unlike the Shuttle EMU LiOH canister and 
sublimator, which provide near-constant vent gas C0 2 and 
dew point levels (i.e., PPC0 2 -0.3 mm Hg and dew point 
-40°F) to the suit, the MOCHR C0 2 and dew point levels 
increase substantially over time and cycle number. 

C0 2 breakthrough (7.6 mmHg) only occurred at high 
metabolic rate levels (i.e., 1400 and 2000 Btu/hr steady 
state). At the more moderate activity levels (i.e., 1000 
Btu/hr average or less), testing was stopped because of 
either water breakthrough (60°F outlet dew point) or time 
and personnel constraints. Therefore, EVA time should 
not be limited by the C0 2 removal performance. 

Although elapsed time to H 2 0 breakthrough 
exceeded 8 hours for much of the test series, H 2 0 
injection rates were not constant and actually decreased 
over time and cycle number because the H 2 0 injection 
rate was limited by a MOCHR inlet dew point constraint 
(to prevent water condensation). H 2 0 breakthrough did 
occur in less than 8 hours in the latter portion of the test 
series (as low as -5.5 hours for a 1000 Btu/hr average 
metabolic rate at cycle 37). Therefore, EVA time may be 
limited by H 2 0 removal performance. 

MOCHR testing showed a decreasing capacity with 
an increasing cycle number. Therefore, the final design 
must account for this reduced capacity to ensure that the 
capacity requirements continue to be met. 
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Alr-Bearlng Fan 
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Abstract 

During advanced space suit studies, we determined 
that a nonintegrated fan with air bearings could contribute 
significantly to enhancing the robustness and reliability of 
a space suit life support system. AiResearch has built a 
small 2 lb fan that can operate from 4 to 23 psia, with 
variable speed from 4 to 8 actual cubic feet per minute, 
running at 95K to 21SK rpm. Performance is very good, 
but further development is needed to prove long life and 
reliability. 

Introduction 

In May 1988, NASA started an effort to develop a 
small, efficient fan for extravehicular activity 
applications. The next-generation space suit differed in 
two major ways from the previous generations of suits. 
New space suit concepts were required to operate at 
pressures as high as 8.3 psi compared to the 4.3 psi of the 
existing Shuttle suit. Advanced water removal concepts 
for the suit did not require the integral water separator that 
the present space suit requires. Additionally, reliability 
studies indicated that the fan was one of the lowest mean 
time between failure (MTBF) components which suggests 
the need to separate the fan, pump, and water separator 
that are driven by a common motor on the Shuttle 
extravehicular mobility unit. The requirement was for a 
small volume and weight air mover that had a high 
MTBF. The fan needed to be more efficient and to draw 
less power for the higher operating pressures of the 
advanced suit. 

Approach/Method 

The approach to solve these new requirements was to 
use air bearing technology to reduce bearing wear and to 
design the aerodynamics of the impeller for the 8.3 psi 
condition. Additionally, the fan was to operate from 4 to 
8 actual cubic feet per minute (ACFM) from 6 to 
23 pounds per square inch absolute (psia). The design 
point was 5 inH z O at 6 ACFM at 8.3 psia vent loop 
pressure. Since space suits often operate in a 100% 
oxygen environment, materials for the fan were carefully 
selected for fire resistance in this environment. The 
oxygen contacting surfaces are made of Inconel 625, 718, 
and 750. Several nonmetallics are used, but the largest 
nonmetallic is the stator winding support that is made 
from Vespel SP-1. 

The permanent magnet motor is a two-pole toothless 
with a three-phase winding. Three Hall-effect sensors are 
used as position sensors for electrical commutation by the 
motor controller. The controller was built using off-the- 


shelf electronics. A flight version will reduce the 8x10x2- 
in prototype box to a 2x2x0.5-in box that uses an 
application specific integrated circuit (ASIC). 

Results 

The fan and its controller are shown in figure 1. A 
line drawing of the portable life support system (PLSS) is 
shown in figure 2. It occupies 19 in 3 and weighs 2 lb. 
Tests were initially run by the contractor at 23, 19.5, 14.7, 
8.3, and 6.0 psia. The results of these tests are shown in 
figure 3. At the design point, the fan provides 5 inH 2 0 
pressure rise at 6 ACFM at 8.3 psia that is drawing 23.6 w 
spinning at 166,000 revolutions per minute (rpm). 
Performance was as expected, except it has a slightly 
higher power requirement. Most of this is because of a 
lower aerodynamic efficiency than was expected. It is 
believed that some of this higher requirement is owing to 
inlet disturbances on the nose cone. The fan was also 
tested over a wider range at JSC. Test results are shown 
in figure 4. These results agreed well with the initial 
contractor results. In-house testing was also done at 
4.0 psi and at a variety of different vent loop pressure 
drops. 

Conclusions 

The air-bearing fan has been a very successful 
technology program. The next step is to build another fan 
that will improve the inlet nose cone aerodynamics and 
reduce the electronics to the ASIC chip. A life cycle test 
program should then be set up to characterize the life of 
the foil bearings and of the electronics. After thousands 
of hours have been demonstrated, a robust fan design will 
be demonstrated that can be used for zero-g, lunar, and 
Mars applications. 
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Figure 1. Air Bearing Fan. 
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Figure 2. PLSS Air-Bearing Ventilation Fan. 
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Figure 3. PLSS Fan Performance Map. 
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Figure 4. ABF Performance Map - JSC Test. 
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Abstract 


System Description 


Long-duration manned space missions will require 
integrated biological and physical/chemical processes to 
recover resources from wastes. In this report, we will 
discuss a hybrid regenerative biological and physical/ 
chemical water recovery system that was designed and built 
in the Gew and Thermal Systems Division. The system is 
sized for a four-person crew and consists of a two-stage, 
aerobic, trickling filter bioreactor; a reverse osmosis system; 
and a photocatalytic oxidation system. The system was 
designed to accommodate high organic and inorganic 
loadings and a low hydraulic loading. The bioreactor was 
designed to oxidize organics to C0 2 and H 2 0; the reverse 
osmosis system reduces inorganic content to potable 
quality; and the photocatalytic oxidation unit reduces 
residual organic content (part per million range) to potable 
quality and provides in situ disinfection. 

Introduction 

For long-duration exploratory space missions, the 
reclamation of water for potable and hygiene uses from 
waste water is of vital importance. Approximately 230 kg 
of waste water are generated by a four-person crew during 
the course of normal daily activities. Efforts to recover this 
water have focused primarily on physical/chemical methods 
such as phase change and/or membrane processes. It is 
likely, however, that because of the additional waste 
components generated in a lunar/Mars habitat, some 
biological method may have sufficient advantages (low 
temperature, low pressure operation, etc.) over physical/ 
chemical methods. The decision was therefore made to 
investigate a hybrid biological and physical/chemical 
system for water reclamation. 

The hybrid regenerative water recovery system 
(HRWRS) is housed in the building 241 facility at JSC. It 
has been funded primarily from Gnter Directorate 
Discretionary funds since start-up in December 1991. 

Problem Statement 

The objectives of the HRWRS are to investigate the 
efficiency of a hybrid system to reclaim potable water from 
waste waters; to determine the chemical characteristics of 
individual sources of waste water, and to assess water usage 
amounts by using current Space Station Freedom (SSF) 
water allotments' and to determine the feasibility of a 
hybrid system for water recovery for long-duration missions 


The system is comprised of two major components: 
the waste water collection and transport system (WWCTS) 
and the three treatment processes (a two-stage aerobic 
trickling filter bioreactor, a reverse osmosis (R.O.) unit, and 
a photocatalytic oxidation system). A schematic of the 
system is shown in figure 1. The components of the system 
are described in detail below. 

Waste Water Collection and Transport System 

The WWCTS is comprised of the five production 
sources (shower, hand wash, urinal, laundry, and 
dishwasher), the facility use control system, the waste water 
production measurement system, and the transport system. 
Although each component of the waste water production 
source was a commercially available item, every effort was 
made to modify the components for limited water usage. 
The operation of the HRWRS is under complete computer 
control. Volunteers provide waste water from shower, hand 
wash, and urinal sources and also provide clothes for 
laundry. Dish wash waste water is provided every other day 
by using dinnerware from the JSC cafeteria. The volumes 
and frequency of collection of waste water from each 
production source are shown in table 1. 

Bloreactor 

Bioreactor design goals were to (1) replace 
pretreatment chemicals required for urine and waste water 
stabilization; (2) stabilize volatiles, such as ammonia, to 
prevent carryover to the R.O. system; and (3) accomplish 
organic removal down to 50 mg/1 or less. The reactor was 
sized for a four-person crew. 

Bloreactor Design 

A fixed-film, aerobic reactor was chosen. The design 
of the bioreactor was based on the mass flow rate of water 
in the system, the expected organic carbon loading of the 
system, and the municipal design criteria. The mass flow 
rate of water in the system was based on Space Station 
water requirements for urine flush, shower, hand wash, and 
laundry water. 1 A two-stage reactor was designed in which 
most of the organic carbon would be removed in the first 
stage and the remainder of the organic carbon would be 
removed in the second stage, with the second reactor also 
accomplishing the nitrification of ammonia. 
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Reactor Fabrication 

Reactors were fabricated from high-strength plastic. 
The first stage is acrylic and has a cross-sectional area of 
335 cm 2 . The second stage is a standard polyethylene tube 
with a cross-sectional area of 190 cm 2 . Both reactors were 
fitted with sample ports and thermocouplers at the inlet and 
the outlet and at depths of 030, 0.91, and 1.52 m into the 
bed. Flow distribution plates were designed to ensure 
distribution of the flow over the entire cross-sectional area 
of the reactor. Underdrains collected effluent water and 
directed the water to small settling tanks at the bottom of the 
reactors. Feed for the downstream processes and for recycle 
around the reactors is drawn from the middle of these 
settling tanks. Air is forced through the reactors from the 
bottom to the top with a blower. 

Reactor Inoculation and Acclimation 

Bioreactors were inoculated with effluent water from 
the Vince Bayou Waste Water Treatment Plant in Pasadena, 
Texas, on December 12, 1991. That plant was chosen 
because it uses a rock-trickling filter as one of the initial 
treatment steps for the waste material, so the residual 
microflora should have been well-adapted to fixed-film 
growth. Also, it is a municipal system with some industry 
effluent feeding into it, which means the microflora were 
expected to be very diverse. The waste concentration was 
slowly increased to full strength. 

Two cartridge filters (35 and 8 microns, respectively) 
were placed in the line between the effluent from bioreactor 
two and the reverse osmosis system to remove large 
particulates and biomass from the water stream. An 
additional 5-micron filter was included on the reverse 
osmosis system itself. 

Reverse Osmosis System 

A commercial reverse osmosis system was procured 
from Applied Membranes (San Marcos, California). The 
system uses two Filmtec seawater-type membranes (spiral 
wound) that are 11.4 cm in diameter, are 101.6 cm in 
length, and are run in series. Unlike most applications for 
R.O., a requirement of 85% recovery of water from the 
bioreactor was imposed. Additionally, the water quality 
requirement for the permeate was less than 100 mg/1 total 
dissolved solids CTDS). At flow rates of 0.76 1/m 
(concentrate), 22.71 1/m (recirculate), and 6.06 1/m 
(permeate), and with the above requirements met, the result 
is a concentrate of approximately 10,000 to 12,000 mg/1 
TDS. Typical operating pressures are 2070-2760 kPa. No 
chemical additives are injected into the system to avoid 
biofouling and/or chemical deposition (as in normal 
operations). Instead, a daily 5-minute flush of the system 
with deionized water is performed. Plans to recover the 
15% water lost as concentrate are now being developed. 


Photocatalytic Oxidation System 

The photocatalytic oxidation system was developed by 
Photocatalytics, Incorporated, under a Phase II small 
business innovative research program. 5 The principle of 
photocatalysis of residual organic material is well known. 
The catalyst material is TiO z , which is made into a slurry 
with deionized water and poured into a 12-liter batch 
reactor. The solution under test is then added to the reactor. 
Ten ultraviolet (UV) lamps (germicidal, 30 W each) are 
concentrically spaced around a central stirrer in the reactor. 
Typical initial total organic carbon (TO Q levels are in the 
30 to 100 mg/1 range (which is the range of TOC values 
from the reverse osmosis permeate). The UV lamps are 
then energized, the stirrer is activated, and a head pressure 
of 69 kPa of oxygen added to the system. Interaction of the 
UV with Ti02 particles produces hydroxyl radicals from 
the surrounding water molecules. This activated hydroxyl 
radical is then able to oxidize the residual organic material 
in the water matrix to produce C0 2 and H 2 0. Depending on 
the initial concentration of organic material, the lamps are 
energized for a period of between 1 and 3 hours. The high 
UV flux also enhances rapid disinfection of the water. 5 

After a period of illumination, the lamps and stirrer are 
switched off, the head pressure of oxygen is removed, and 
the resulting purified water is removed from the reactor. 

The finely divided catalyst particles are removed from the 
product water by cross-flow filtration. The principle of 
cross-flow filtration is the mechanical removal of particles 
through a fine mesh filter using a back pressure on the filter 
to obtain filtrate (product water). As catalyst material builds 
up on the filter, however, the head pressure becomes 
insufficient for efficient filtration. At this stage, the filter is 
back-flushed with a burst of 172.5 kPa water. The result is 
that catalyst is flushed off the membrane and back into the 
reactor. 

Results 

Bloreactor 

The WWCTS became operational on March 5, 1992. 
Subsequently, the feed to the reactors was collected from 
the urinal, shower, hand wash, laundry, and dishwasher. 
Additional make-up urine or soap was added if there were 
insufficient test subjects to obtain the equivalent of a 
4-person use in 1 day. 

Bioreactor performance was determined based on 
reduction in TOC from inlet to outlet, reduction in ion 
concentrations from inlet to outlet, the dissolved oxygen 
profile of the system, and visual observation of the biomass. 
Other parameters that were measured occasionally included 
pH, total dissolved solids, and inorganic carbon (IC) 
content. 

Bioreactor performance over the 2 months of October 
and November, when the system water allotments were 
reduced to SSF allocations is shown in figure 2. As can be 
seen, the effluent TOC from the second reactor was 
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consistently below 50 mg/1 although the influent TOC 
ranged from 80 to 650 mg/1. This indicates that the 
microorganisms are robust and that they rapidly respond to 
changes in influent concentration. The reactors have 
achieved an average TOC reduction of 90% since water 
allotments have been at SSF levels and a total reduction of 
81.4% since start-up in December 1991. The molar ratio of 
nitrate to ammonia for the influent and effluent streams and 
the sulfate concentration for the same two streams during 
the 2-month period from October to December are shown in 
figure 3. The increase in the ratio of nitrate to ammonia in 
the effluent indicates that the reactors are nitrifying 
ammonia to nitrate and then to nitrogen gas. 

Accomplishing this conversion was one of the objectives of 
the system. The increase in sulfate concentration from 
influent to effluent is evidence that the soap used in the 
shower and hand-wash is being degraded by the microbial 
population. Overall, the TOC and ion chromatography 
results indicate that the reactors are performing as designed. 

Reverse Osmosis System 

Analysis of R.O. performance is based on two factors: 
percent recovery and percent rejection. In terms of percent 
recovery, during long-term testing, the system continually 
operated at between 85 and 87% recovery and at a permeate 
quality of below 75 mg/1 TDS. During functional checkout 
of the system, however, several tests were performed on 
standard solutions up to 2200 mg/1 TDS, at varying 
recovery percentages. Results of these preliminary tests are 
given in table 2. 

Photocatalytic Oxidation System 

A typical organic carbon profile as a function of time is 
shown in figure 4. It can be seen that the availability of 
organic material for oxidation becomes rate limiting at 
concentrations of 3 to 4 mg/1. The increase in IC is because 
of the buildup of C02 (in equilibrium with the carbonate 
ion). At a limiting concentration (-14 mg/1) of dissolved 
C02 and with the reactor temperature increasing, the level 
of IC decreases to -10 mg/1. To date, no carryover of 
catalyst in the product water has been observed. The 
principle of operation has been proved. 

Conclusions 

It has been demonstrated that a hybrid biological and 
physical/chemical system is capable of treating waste water 
from shower, urinal, hand wash, laundry, and dishwasher 
sources and can produce potable water from such waste 
water. 

A facility now exists that is automated to collect and 
process waste water. The system has flexibility for testing 
and evaluating biological and physical/chemical water 
recovery system processes. 

The bioreactor has been in operation for 13 interrupted 
months and is removing organic impurities from the waste 


water. The reverse osmosis system is demonstrating the 
ability to remove dissolved solids. 

The major difficulties encountered during this period of 
investigation have been mechanical in nature. Specifically, 
mechanical difficulties are associated with pump design for 
low flow rates with high suspended solids levels. 

The batch operational features of the photocatalytic 
oxidation system makes it unsuitable for complete system 
integration. This system will be replaced with an improved 
posttreatment system that is currently in fabrication. 

System closure will be maximized by (1) the recovery 
of the 15% brine from the reverse osmosis system; (2) the 
closure of the gas loop from the bioreactor effluent; and 
(3) the development of a methodology for the treatment of 
bioreactor solids. 

No expendable materials have been used in the 
HRWRS except for infrequent change out of cartridge 
filters between the bioreactors and the reverse osmosis 
system. This represents a substantial advantage over past 
and present water recovery systems. 
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Table 1. Production Sources Use Mass and Frequency 


Production Source 

Mass per Use 

0<g) 

Uses per Day 

Shower 

10.89 

4 

Urinal* 

0.50 

16 

Hand Wash 

2.04 

16 

Laundry 

99.80 

1 

Dishwasher 

45.72 

0.5 

Total Mass per Day (kg) 

206.86 

- 


* Includes 0.125 kg per use flush water 


Table 2. Reverse Osmosis Performance on Standard Test Solution 


Ion 

Feed 

(mg/I) 

Permeate 1 

27 % 

Recovery 

(mg/I) 

Rejection 

(%) 

Permeate 2 
53% 

Recovery 

(mg/I) 

Rejection 

(%) 

Permeate 3 
85% 

Recovery 

(mg/I) 

Rejection 

(%) 

Cl (-) 

556.50 

1.50 

99.73 

2.65 

99.52 

5.40 

99.03 

P0 4 (3-) 

500.00 

0.25 

99.95 

0.40 

99.92 

0.85 

99.83 

S0 4 (2-) 

355.00 

0.15 

99.96 

0.25 

99.93 

0.60 

99.83 

Na (+) 

512.50 

0.80 

99.84 

1.55 

99.70 

3.10 

99.40 

Mg (2+) 

30.00 

0.05 

99.83 

0.05 

99.83 

0.10 

99.67 

Ca (2+) 

1.75 

0.05 

97.14 

0.10 

94.29 

0.10 

94.29 

K (+) 

251.50 

0.27 

99.89 

0.49 

99.81 

1.09 

99.57 

TDS (mg/I) 

2207.25 

3.07 


5.49 


11.24 
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Two-Phase Pressure Drop of Ammonia in Small Diameter 
Horizontal Tubes: Experimental Results 

Eugene K. Ungar and John D. Cornwell 
Johnson Space Center/EC 


Abstract 

Data for pressure drop in adiabatic two-phase ammonia 
flows in small diameter horizontal tubes are presented. The 
data has direct application to the sizing of the flow-through 
radiator tubes in the Space Station Freedom heat rejection 
system. The data are compared to existing correlations for 
pressure drop and are found to be significantly lower than 
the most commonly used correlations. However, several of 
the less commonly used correlations predict the data 
accurately. A recommendation is made for a method to 
accurately predict the pressure drop in two-phase ammonia 
flows in small horizontal tubes. 


Nomenclature 


A 

cross-section area of tube, (ji/4)d 2 

(ft 2 ) 

d 

diameter 

(f») 


mass flow rate 

(lbm/s) 

Ref 

Reynolds number of the liquid 
as if it were flowing alone, pfUfd/pf 


Re g 

Reynolds number of the vapor as if 
it were flowing alone, pgUgd/pg 
superficial velocity of the liquid, 


«f 



(l-x)/(pfA) 

(ft/s) 


superficial velocity of the vapor, x/(p g A) 

(ft/s) 

X 

quality 


W 

absolute viscosity of the liquid phase 

(lbm/ft s) 

H 

absolute viscosity of the vapor phase 

(lbm/ft s) 

Pf 

density of the liquid phase 

(lbm/ft 2 ) 

Pg 

density of the vapor phase 

(lbm/ft 2 ) 


Introduction 


The Space Station Freedom (SSF) will be assembled 
on-orbit between November 1995 and December 1999. The 
SSF Active Thermal Control System (ATCS) acquires 
waste heat from the manned modules and the outboard 
electric components and rejects the heat through radiation to 
space (figure 1). The ATCS consists of three two-phase 
ammonia flow loops, one with a setpoint of 58°F, the other 
two with setpoints of 35°F. In each flow loop, liquid 
ammonia is partially vaporized at multiple heat acquisition 
sites and is returned to the pump module. Here the liquid 
and vapor are separated. The liquid is returned to the heat 
acquisition sites and the vapor is transported to the radiator 
array, where it is condensed and slightly subcooled. The 
condensed liquid is then returned to the pump module. 

The ATCS heat rejection system consists of two arrays 
of three flow-through radiator orbital replacement units 


(ORUs) each. The starboard wing contains the heat 
rejection for the two 35°F setpoint flow loops. The port 
wing contains the heat rejection for the 58°F setpoint flow 
loop. Each ORU contains eight panels as shown in figure 2, 
each 10.08 ft by 8.67 ft. Each panel contains 22 evenly 
spaced flow tubes as is shown in figure 3. The flow tubes 
are 10.5 ft long and are connected in parallel by manifolds 
that run the length of each ORU. The three ORUs in each 
array are connected in parallel. 

The SSF ATCS imposes strict requirements on the 
radiator array pressure drop. A total of 1.4 psi is available 
for pressure drop through the ORUs. In order to maintain as 
even a flow distribution as possible, 1.0 psi is allocated for 
the pressure drop in the flow tubes, with the remainder 
allocated for the manifolds, other plumbing, and fittings. 

Knowledge of the pressure drop in the flow tubes is of 
critical importance. If the allocated pressure drop is 
exceeded at the design point (maximum load), the total 
allocated radiator array pressure drop will be exceeded, 
which would cause difficulty in maintaining the ATCS 
setpoint. If the pressure drop at maximum load is 
significantly less then the 1 psi allocated, the flow 
distribution in the radiator ORU will suffer, which would 
lower the total heat rejection capability of the array. 

Using the two-phase flow pressure drop prediction 
methods in the literature, a tube size of 0.093 in was 
provisionally selected to yield the desired pressure drop. 
However, there was a great deal of concern over the 
accuracy of this sizing because the pressure drop prediction 
methods in the literature were developed for large tubes 
(diameter on the order of 1 in). Also, a literature search 
showed that only minimal experimental work in the low 
quality range had been performed on two-phase flows in 
small diameter tubes. 1,2 Therefore, it was decided to 
perform a series of tests to investigate the pressure drop for 
two-phase ammonia flows in SSF radiator-sized tubes. The 
adiabatic pressure drop tests performed at NASA Johnson 
Space Center that are reported here were complemented by 
tests of the pressure drop in condensing ammonia flows in 
SSF-sized tubes that were performed concurrently at LTV 
Missiles and Space Company 3 (now Loral Vought Systems 
Co.). 

Together the two tests were designed to yield sizing 
information for the SSF radiator tubes and information to 
allow prediction of the on-orbit performance of the SSF 
radiator array. As a result of these experiments, a final tube 
size of 0.067 in was selected to provide the required 
pressure drop in the flow-through radiators. 
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Test Rationale 

The pressure drop in the SSF flow-through radiators 
consists of the frictional pressure drop minus the pressure 
recovery owing to condensation. The frictional pressure 
drop at any point should be identical to the pressure drop in 
adiabatic two-phase flow owing to the small quality 
gradient in the tubes (the tube length is approximately 
2000 diameters). In the SSF radiators, the pressure recovery 
is only a few percent of the frictional pressure drop and can 
be easily estimated. Therefore, predicting the two-phase 
adiabatic pressure drop is the first and most important step 
in predicting the pressure drop in the SSF flow-through 
radiator tubes. 

Ground tests were performed to measure the adiabatic 
two-phase pressure drop because, owing to the small tube 
size and the fairly high vapor velocity for the SSF radiator 
tubes, it was expected that the flow regime and thus the 
pressure drop in Earth-normal gravity (1-g) would be the 
same as in the microgravity (0-g) of flight. Possible two- 
phase flow regimes in horizontal tubes at 1-g are annular, 
stratified, intermittent (slug), and dispersed bubble. For our 
case, as long as the flow regime is not stratified, the flow 
regimes and the pressure drops are expected to be the same 
in 1-g as in 0-g. 

The 1-g operating conditions for SSF flow-through 
radiator-size tubes for SSF flow rates were compared to 
Taitel and Dukler’s 4 prediction for the transition between 
the annular and stratified flow regimes. The limits indicate 
that annular flow will exist for qualities above 
approximately 10% in Earth-normal gravity. That is, the 
pressure drop in 90% of the two-phase length should be the 
same in 1-g and in 0-g. Because the pressure gradient is 
largest by far in the high quality region of the radiator tube, 
using a 1-g based prediction that is accurate from 100% to 
10% quality will provide a pressure drop prediction with an 
error significantly less than 10%. 

Based on these arguments, it was decided that adiabatic 
ground testing of the appropriate tube size, quality, and 
ammonia mass flow rates would provide pressure drop 
information directly applicable to the SSF radiator design. 

Literature 

There are many predictions of the pressure drop in two- 
phase flow available in the literature. Some of the most 
commonly used predictions are briefly described below: 

• Homogeneous predictions treat the two-phase flow as a 
single fluid with mixture properties. All the mixture 
properties except viscosity can be easily found. The most 
commonly used mixture viscosity representation is that of 
McAdams et al. 5 

• Lockhart and Martinelli 6 proposed a prediction based on a 
large number of pressure drop measurements for one- and 
two-component two-phase mixtures. Their correlation is 
generally considered to be accurate for the case of annular 
flow. 

• Asali, Hanratty, and Andreussi 7 proposed an annular flow 


correlation that includes the effects of the thickness and 
roughness of the liquid film on the pressure drop. 

• Crowley and Izenson 8 extended Wallis’s 9 liquid/vapor 
interface Darcy friction factor correlation to allow the 
prediction of pressure drop in annular flow. 

• In the smooth annular prediction, the Darcy friction factor 
for the liquid/vapor interface is taken to be the same as if 
the vapor were flowing alone in the tube. In comparison, 
the Darcy interfacial friction factor in Crowley and 
Izenson’s model is typically an order of magnitude higher 
than it is for a smooth interface. 

Experiment 

A series of adiabatic two-phase ammonia pressure drop 
tests were performed at NASA/Johnson Space Center in 
October 1991. In these tests, a known mass flow rate of 
two-phase ammonia at a known quality was passed through 
horizontal tubes of 0.0575, 0.0701, 0.1017 and 0.1240 in 
diameter. The test sections were each 10 ft long with 3 ft 
inlet and 1 ft outlet sections of the same diameter as the test 
section. A precision differential pressure transducer sensed 
the pressure drop across the 10 ft length. A more complete 
description of the experimental apparatus, as well as the 
experiment methodology and the test results can be found in 
ref. 10 

Results 

A total of 134 steady-state two-phase flow pressure 
drop data points were obtained for the four tube sizes at 
various mass flow rates and qualities. The superficial liquid 
Reynolds numbers (Re f ) for all the data were less than 700. 
The superficial vapor Reynolds numbers (Re^) ranged from 
450 to 11,000. Also, a limited number of pressure drop data 
points for subcooled liquid and superheated vapor flows 
were obtained. These data verified that the instrumentation 
was accurate. Representative two-phase pressure drop data 
are compared with the various predictions for the same 
nominal conditions in figures 4, 5, 6, and 7. The figures 
show a trend that is consistent in all the data obtained in this 
test. The Crowley and Izenson prediction and the Lockhart- 
Martinelli prediction both consistently overpredict the data 
by a significant amount. In contrast, the McAdams et al. 
homogeneous prediction, the smooth annular prediction, 
and the prediction of Asali et al. all match the data very 
well. Table 1 contains a summary of the RMS errors for the 
more accurate predictions when applied to the present data. 

Figures 8 and 9 show comparisons between all the 
present two-phase data and the McAdams et al. prediction, 
and the prediction of Asali et al. The data is predicted 
equally well by both methods. 

The Lockhart-Martinelli prediction is the standard for 
predicting pressure drop for annular flow in large tubes. 
Previous ammonia testing at JSC has indicated that for 
horizontal tubes of 0.620 and 0.706 in diameter the two- 
phase pressure drop is well predicted by the Lockhart- 
Martinelli correlation. 11 However, the Lockhart-Martinelli 
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correlation does not fit the present data for small diameter 
tubes. This unsuitability is not surprising considering that 
the Lockhart-Martinelli prediction was developed mainly 
from steam and air/liquid data in tubes with diameters on 
the order of one inch. Surface tension has a much stronger 
influence on two-phase flow in smaller tubes. Here surface 
tension effects could tend to smooth the liquid/vapor 
interface and hence reduce the pressure drop in annular 
flow. This explanation is supported by the good correlation 
of our data with the smoothannular model and by the 
accuracy of the correlation of Asali et al. which, for our 
data, has interfacial friction factors approximately equal to 
the Darcy friction factor if the vapor were flowing alone. 
Duschatko’s et al. 3 concurrent condensing flow experiments 
yielded results in excellent agreement with our own. 

Conclusions 

The pressure drop for two-phase ammonia flows in 
small diameter tubes cannot be predicted with acceptable 
accuracy using the techniques normally used for large tubes. 
The pressure drop data obtained in the present work is 
equally well predicted by the McAdams et al. homogeneous 
prediction and by the Asali et al. annular flow prediction. 
Because of its ease of calculation, the McAdams et al. 
homogeneous pressure drop prediction has been 
recommended for use in sizing the SSF ATCS flow-through 
radiator tubes to yield an acceptable pressure drop. 
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Table 1 - Comparison of Existing Prediction Methods for the Present Data 


Prediction Type 

Reg<1500 

RMS error 
Re e >1500 all 

Lockhart-Martinelli 

70.6% 

100% 

95.9% 

Smooth Annular 

160% 

233% 

34.4% 

McAdams et al. 

333% 

21.2% 

23.8% 

Asali et al. 

30.7% 

183% 

21.2% 
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Figure 1. Space Station Freedom. 



Figure 2. Radiator Panel Array (typ.). 



Figure 3. SSF Flow-Through Radiator Panel. 
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Figure 6. Data and Predictions for 
0.1017 inch tube, 1.24 Ibm/hr, 74°F. 
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Figure 7. Data and Predictions for 
0.1240 inch tube, 1.75 Ibm/hr, 74°F. 




Figure 8. Comparison of Present 
Data with the McAdams et al. Prediction. 


Figure 9. Comparison of Present Data 
with the Asali et al. Prediction. 
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Abstract 

The program entitled “Two-Phase Flow 
Characterization for Fluid Components and Variable 
Gravity Conditions” was initiated by JSC to investigate 
vapor-liquid flow regimes and pressure drops in pipe 
components under variable gravity conditions. The 
program supports the Space Station Freedom (SSF) 
external active thermal control system (ATCS) and utility 
distribution system designs as well as future space 
missions, including the proposed Moon/Mars missions. 
Objectives for the program include studying two-phase 
flow behavior in fluid components (smooth pipes, bellows 
lines, quick-disconnect fittings), expanding the two-phase 
data base for zero-g conditions, developing a data base for 
low-g conditions (Moon g, Mars g), and validating 
models for two-phase flow analyses. Zero-g and low-g 
data were gathered using a Freon-12 flow loop during five 
test series on the NASA KC-135 aircraft. 

A large flow regime data base was developed for 
smooth tubes in four gravity levels (zero g, 1/6 g (Moon), 
V 3 g (Mars), one g). More limited pressure drop data were 
also obtained for the smooth tubes and component test 
sections for zero-g and low-g conditions. This program 
produced the first published, low-g, two-phase data and 
also provided data to support the SSF Program. 

Introduction 

Programs that require increased waste thermal power 
levels caused an evolution in space system thermal 
control from conduction paths to single-phase working 
fluid loops. The SSF will employ the next step in that 
evolution because its higher power levels and longer 
transport distances have led to the use of a two-phase 
ammonia working fluid system, the ATCS. This system 
will provide a virtually isothermal energy sink at lower 
mass and pump power than would be possible with a 
single-phase system. Future space missions, such as the 
proposed Moon/Mars missions, will have even more 
demanding thermal management requirements. The full 
potential of two-phase systems will be used to make these 
missions more viable. The highly complex phenomena of 
two-phase flow often requires empirical treatment, 
however, and at the time this program was initiated, 
zero-g data were sparse and there were no published 
low-g data. 

JSC has had previous experience in the research and 
development of two-phase space systems, including: 
reduced-gravity flight experiments on the KC-135 


aircraft u ; ground and Shuttle flight experiments of heat 
pipes 3 - 4 ; and, most notably, ground evaluation and 
development of two-phase thermal control systems for 
SSF. 

The JSC project described in this report was a 
KC-135-based experimentation effort initiated in fiscal 
year 1991 (FY91). The following sections present the 
problem statement, program overview, and some 
available results. 

Problem Statement 

As stated previously, the highly complex nature of 
two-phase flows, the sparsity of associated microgravity 
data, and the lack of any low-g, two-phase data were all 
drivers for initiating the program. Objectives for the 
program included studying two-phase flow behavior in 
fluid components (smooth pipes, bellows lines, quick- 
disconnect fittings), expanding the two-phase data base 
for zero-g conditions, developing a data base for low-g 
conditions (Moon g, Mars g), and validating models for 
two-phase flow analyses. 

Program Overview 

The following paragraphs provide a brief overview of 
the program. This overview includes a description of the 
test package, brief sections on the flow regime and 
pressure drop testing, and a summary of the test flights. 

Experiment Package Description 

The experiment package, shown schematically in 
figure 1, was developed by Foster-Miller Inc. as part of a 
Phase II small business innovative research contract 
performed for the United States Air Force (USAF) 

Phillips Laboratory at Kirtland Air Force Base. The 
Phillips Laboratory/Foster-Miller package was selected 
for this program because of its history of KC-135 flight 
testing during 1990. 6 The USAF agreed to loan the test 
package to the JSC for the 2-year project. 

The experiment package was delivered to the 
Thermochemical Test Area at JSC in April 1991 to 
undergo modifications. Alterations were made to the 
package to enable different components’ testing and to 
allow for a wider range of flow rates of both the liquid 
and vapor phases. After modifications, the experiment 
package contained two adiabatic test sections that had 
1.2-m (48-in.) length and a straight inlet length of -0.6 m 
(24 in). The smooth pipe test sections had 10.4-mm 
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(0.41-in.) and 4.6- mm (0.18-in) inner diameters. Vapor 
flow measurements were made with a low-range or a 
high-range venturi meter. Liquid flow measurements 
were taken with a low-range or a high-range turbine-type 
meter. Combining the minimum measurable flows with 
the pump upper limit allowed flow rates of roughly 
0.001 to 0.090 kg/s (713 lbm/hr) of liquid and 
0.001 to 0.010 kg/s (79 lbm/hr) of vapor. A more detailed 
description of the package after modifications can be 
found in the report by Best. 7 

In addition to being well proven on the KC-135, this 
test loop offered a unique characteristic by employing a 
Foster-Miller two-phase pump, which could process inlet 
mixtures of any quality. Freon-12 was selected for the 
working fluid because of its low toxicity, heat of 
vaporization, low surface tension, material compatibility 
properties, and high vapor density at acceptable pressures. 
Nominal operating conditions were 588.4 kPa (85 psia) 
and 294 K (70 # F). 

Flow Regime Testing 

Flow regimes are the spatial distributions of liquid 
and vapor phases flowing in a pipe. The prediction of 
other parameters, such as pressure drop and heat transfer 
coefficient, is specific to the flow regime experienced. 

The project’s goal for predicting flow regime transitions 
and, thus, characterizing two-phase flows was to develop 
a model that could be used for a wide range of fluids and 
environmental conditions, including the reduced gravity 
of the Moon or Mars and the zero g on orbit. 

Pressure Drop Testing 

Pressure drop can profoundly affect pipe and pump 
sizing — and, hence, the mass and power — of two-phase 
thermal control systems. These effects are particularly 
critical for space systems, where penalties for under- or 
over-designing are significant. The pressure drop testing 
of this project had two thrusts: to provide one- and zero-g 
two-phase pressure drop data through fluid components to 
verify design procedures for the Space Station external 
ATCS and utility distribution system, and to provide 
pressure drop data for smooth pipes at different gravity 
levels. 

Flight Series 

Zero-g and low-g, two-phase flow data were gathered 
on five flight series onboard the NASA KC-135 aircraft 
during FY91 and FY92. More than 500 parabolas were 
flown. A picture of the experiment package in its test 
configuration onboard the KC-135 is shown in figure 2. 

The following list summarizes the time frame and 
gravity levels of the flight tests completed: 

• Flight Series I, August 19-23, 1991, four zero-g flights 

• Flight Series II, November 19-21, 1991, three zero-g 
flights 


• Flight Series III, December 17-20, 1991, one zero-g and 
three Moon-g flights 

• Flight Series IV, January 22-31, 1992, two zero-g, one 
Moon-g and one Mars-g flights 

• Flight Series V, July 7-10, 1992, two zero-g and two 
Mars-g flights 

Results 

A large flow regime data base has been developed for 
smooth tubes in four gravity levels (zero g, '/ 6 g (Moon), 
V, g (Mars), and one g). Results indicate the existence of 
a unique flow regime for low-g conditions, a regime that 
is presently named stratified/annular. This regime is 
similar to the annular regime normally seen in zero g with 
the exception that the fluid film coating the tube is much 
thicker on the bottom than on the top because of low 
gravity effects. Flow regime data obtained for Mars-g are 
shown in figure 3. 

Approximate regions are shown (fig. 3) for the major 
flow regimes as seen under Mars-g conditions (stratified, 
plug, stratified/annular, and annular). Some overlap of 
the data is evident, and this overlap is representative of 
the transition zone for flow regimes. Work is continuing 
on comparison of these data to existing and developed 
flow regime models. 

More limited pressure drop data were also obtained 
for the smooth tubes and component test sections for 
zero-g and low-g conditions. Analyses are continuing to 
interpret these data for the final report. 

Conclusions 

This program has produced the first published, low-g, 
two-phase flow regime and pressure drop data, and has 
also provided data to support the SSF Program. Project 
results will be documented in an internal JSC report, 
“JSC-32261 Two-Phase Flow Characterization for Fluid 
Components and Four Gravity Levels,” which is expected 
to be published in early 1993. The Crew and Thermal 
Systems Division at JSC is currently pursuing an orbital 
flight experiment through the INSTEP program as the 
next major technical step in the advancement of two- 
phase flow systems and modeling. 
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Figure 1. Two-Phase Experiment Loop Schematic, Post-Modifications (Best 1991). 
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Abstract 

A simple, nonintrusive electromagnetic probe has 
been developed that can measure instantaneous changes 
in the flow rates of two fluids or two states of a single 
fluid. This technique makes the measurements by 
distinguishing between the differences in the dielectric 
constants of the two liquids or gas/liquid phases of the 
same fluid. Possible NASA applications include 
measurements of helium/hydrazine flow during rocket 
tests at White Sands Test Facility, liquid/gas flow in 
hydrogen or oxygen lines in Orbiter engines, and liquid/ 
gaseous Freon” flow in zero g tests with the KC-135 
aircraft at JSC. 

Introduction 

Ground testing of reaction control system (RCS) 
thrusters at the White Sands Test Facility (WSTF) are 
constrained by not being able to measure helium and 
hydrazine flowing through inlet pipes to the thruster 
engine. A microwave technique has been developed that 
can measure instantaneous flow rates of two liquids or 
two states of a single fluid. This technique, which is 
sensitive to the dielectric constants of two liquids or 
liquid/gas phasers, has numerous NASA applications: 

• monitoring of the aforementioned helium and hydrazine 
flowing through inlet pipes to RCS thrusters 

• monitoring of Freon conditions in zero g 

• monitoring of liquid/gaseous conditions in cryogenic 
hydrogen or oxygen flow lines 

• monitoring of water/gas flow in flapper valve tests at 
JSC 

• determining the existence of bubbles on a flow line 

System Description 

In this system, a microwave coaxial transmission line 
is inserted through the wall of the pipe into the fluid(s). 
The center pin of the small probe has minimal extension 
into the fluid inside the pipe. The fluid acts as a load 
impedance on the transmission line, and this load varies 
with the changes in the effective dielectric constant of the 
fluids changes as the fluids flow past. 

A microwave signal is continuously transmitted 
down the coaxial line into the pipe, and a reflected signal 
travels back. This reflected signal is dependent upon the 
S„ parameter as defined by 


Sll =_Za_iZL.= Pe-j 0 
Zo + Zl 

where 

Z 0 is the characteristic impedance of the 
coaxial line (50 Ohms) 

Z L is the load impedance on the coax 
due to the fluid within the pipe 
6 is the angle of the complex SI, parameter, which is 
dependent upon the effective dielectric constant of 
the fluid in the pipe. 

The system essentially measures the instantaneous 
phase angle of the reflected signal from the terminated 
probe within the pipe. The amount of the phase shift 
measured when the flow changes from all liquid 1 to all 
liquid 2 is dependent upon the dielectric constants of the 
two liquids. Similarly, measurements of the liquid/gas 
phases of the same fluid are dependent upon the dielectric 
constants of the liquid and the gas. It is a simpler task to 
measure changes in two liquids flowing through a pipe 
than it is to measure differences in the flow rates of liquid 
and gas states of the same fluid. This is because the 
dielectric constants of the liquid and gas states of 
cryogenic fluids are usually very close to the same values. 

The electronic circuitry used to measure the 
instantaneous changes in phase as a function of time is 
shown in figure 1. In this system, a dual phase detector is 
used to measure the inphase component (I-channel) and 
quadrature component (Q-channel) of the instantaneous 
phase of the reflected signal. The “I” and “Q” channel 
outputs make the system easier to calibrate and to 
minimize long-term phase drifts within the electronics. 

The DC output voltages from the phase detector are 
converted to digital data using an A/D converter as part of 
a data acquisition board integrated with a personal 
computer. The software has been customized to control 
the measurement rate and scaling of the data to maximize 
the frequency shifts for the individual dielectric constants 
of the fluids under measurement. The data for a single 
measurement run can be placed in a file for display in 
graphical form for immediate analysis or transferred to a 
disc for later processing. A block diagram of the 
complete electromagnetic probe system (hardware and 
software) is shown in figure 2. 

Software has also been written to calculate the 
average value of the measurement run or any portion of 
the run. This calculation allows a valve for the average 
relative dielectric constant to be obtained. 
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Proof-of-Concept Tests 


Summary 


A complete system was built and tested in a field 
environment at the JSC A Shuttle Program "flapper 
valve test” was conducted in building 356 in February 
1992 in which deionized water and gaseous nitrogen were 
pumped at various flow rates through a specific flapper 
valve. The purpose of the tests was to determine the 
spring wear dynamics on the valve. For each flow rate 
(10 gal to 50 gal per min), the percentage of N 2 was 
varied from 10% to 75%. 

All measurement runs for the microwave sensor were 
for a period of 10 sec. During this period, 6000 measure- 
ments were made and reported. A sample measurement 
run of the instantaneous nitrogen gas and water through 
the inlet pipe to the flapper valve is shown in figure 3. In 
this data collection, the percentage nitrogen is referred to 
as the void fraction. The data in figure 3 show the effects 
on large gas bubbles (little or no water present) as well as 
small bubble perturbations within the water flow. Visible 
observations of the water/gas flow through the clear tube 
confirmed this flow characteristic. 


When fluids are flowing rapidly through a pipe, a 
flush-mounted or a short probe may be necessary so as 
not to disturb the flow. For the test programs to date, a 
probe length into the fluid of 0 to 2 mm has been used. 
The short probe "sees” fluid only a short distance away. 

If necessary to see farther into the media, an increase in 
probe length is needed to increase the effective fluid 
volume that influences the probe load impedance. A 
higher resonance frequency for the probe may also 
increase the effective volume. 

To summarize, a microwave technique has been 
developed and tested that measures the change of phase of 
a reflected signal from a transmission line probe 
terminated within a fluid inside a pipe. The hardware and 
software can be optimized to enhance the measurement 
sensitivity of a system that measures a particular fluid. 
This system, which can be used in both NASA and 
commercial applications, is considered unique and will be 
patented. 



Figure 1. Phase Detector Block Diagram. 
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Figure 3. Flapper Valve Experiment Using Distilled Water and Air. 
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Abstract 

A high temperature superconductivity (HTSC) flight 
experiment from the payload bay of the Space Shuttle 
Orbiter to the advanced communications technology 
satellite (ACTS) is being breadboarded. This proposed 
experiment, a joint project between JSC and the Lewis 
Research Center, would use a Ka-band (20 GHz) HTSC 
phased array antenna and front-end electronics (low noise 
amplifier) to received a downlink communications signal 
from the ACTS. A conventional receiver demodulates the 
encoded telemetry signal, which is then turned around and 
transmitted back to ACTS and the ground. 

The HTSC phased array has nine 4x4 microstrip 
patch antenna subarrays, which, when properly phased, 
provide approximately 24 dB of boresight gain. An 8x8 
HTSC microstrip patch array has been built and tested. A 
Ka-band receiver, transmitter, modem, encoder, decoder, 
etc., are now being built and tested. Link analyses and 
interface problems with the Orbiter are addressed in the 
paper in addition to the design, fabrication, and testing of 
various subsystems used in the communication link. 

Introduction 

The recent discovery of high temperature 
superconductivities (HTSCs) has focused attention on the 
search for applications that will enhance the performance 
of communications systems. With the natural cooling 
abilities of space under certain conditions, potential space 
applications are attractive. One application is the use of 
HTSC materials in microwave and mm-wave feed 
networks for large antenna arrays. This application could 
enhance the communications system performance, 
primarily by reducing front-end losses, but by also 
allowing bulky waveguide feed structures to be replaced 
with smaller, high performance planar structures. 

This paper describes a proposed HTSC mm-wave 
communications flight experiment between a Shuttle 
Orbiter in low Earth orbit (LEO) and the advanced 
communications technology satellite (ACTS) in geo- 
synchronous orbit. The experiment involves a Ka-band, 
superconducting phased array antenna with the front-end 
electronics developed by the Lewis Research Center 
(LeRC) and the receiver, with appropriate interfaces in an 
Orbiter payload bay, developed by JSC personnel. 
Breadboard hardware for the various subsystems are 
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being built and tested. The expected timeframe for the 
experiment is 1996. The advantages of such an 
experiment include 

• the first use of a complete HTSC communications 
system operating in a manned spacecraft environment, 

• an evaluation of the thermal interfaces, cooling rates, 
and interfaces required for an HTSC system to work in 
an operational space environment, 

• provides direct distribution of data from the ground to a 
spacecraft without the additional hops involved in the 
present communication links through the Whites Sands 
Test Facility, and 

• the first utilization of the 19.7 GHz forward link from 
the ACTS to an orbiting spacecraft. 

System Configuration 

The ACTS is an experimental, geosynchronous 
satellite scheduled to be launched in February 1993 with a 
4-yr expected operational lifetime. This satellite, which 
has been designed and developed by the LeRC, provides 
spot beams to fixed ground locations within the United 
States. It also has a 1.1m, computer steerable antenna that 
can communicate with LEO spacecraft. The system 
configuration, as shown in figure 1, has an uplink signal 
at 29.5 GHz, which is transmitted from the Electronic 
Systems Test Laboratory (ESTL) at JSC or from the 
LeRC to the ACTS. The signal is received by the 2.2m 
antenna on the ACTS, routed via a matrix switch to the 
1.1m antenna, which transmits the signal at 19.7 GHz to 
the Orbiter. This is a bent-pipe mode within the ACTS 
with a 900 MHz IF bandwidth. The maximum Doppler 
shift during the experiment is approximately 500 MHz, 
which exceeds the capability of the ACTS baseband 
processing mode (demodulation/modulation). 

The experiment program includes development of the 
space hardware for the Orbiter as well as ground 
transmitting equipment needed in the ESTL. In addition, 
the program includes certification testing and 
documentation required for flight on the Orbiter, 
integration into the payload bay, and the interfaces with 
the other Orbiter equipment. Certification testing 
includes four areas: thermal vacuum, vibration, structural 
loads, and electromagnetic interference (EMI). The 
experiment is categorized as a Class C payload 
(economically reflyable or repeatable) with no Orbiter 
impacts in the event of an experiment failure. 
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A detailed block diagram of the spacecraft equipment 
is given in figure 2. The HTSC antenna could be a 
circular polarized phased array with nine subarrays; each 
subarray has 4x4 microstrip patch antennas. This antenna 
will be discussed in detail later in the paper. The antenna 
has approximately 25 dB of gain with a 10* half power 
beamwidth. Each of the nine subarrays feeds a low-noise 
amplifier, followed by a monolithic microwave integrated 
circuit (MMIC) phase shifter. The phase shifters are 
controlled by a dedicated antenna controller that takes the 
state vector of the Orbiter from the payload interface 
panel and calculates the required phase shifter settings to 
point the beam electronically. Mechanical pointing 
requirements, as determined by the 3 dB beamwidth of a 
subarray, are approximately ±15* for boresight alignment. 

Ground Equipment 

The ground terminal at JSC has a 1.2m parabolic 
antenna, which is manually pointed to the ACTS. A 
baseband signal, 100 Kbps to 300 Kbps with 
convolutional encoding, is biphase modulated onto uplink 
carrier. The type of modulation data has not been 
determined. 

Spacecraft Receiver 

The spacecraft receiver requires either a large sweep 
bandwidth to acquire the Doppler shifted signal of 
±500 MHz with a maximum rate of change of 0.6 KHz/ 
sec, or the ground transmitter must have a 
preprogrammed emphemeris to compensate for the 
Doppler shift. It will probably be easier and less costly to 
Doppler compensate on the ground. Also, it has not been 
decided whether to record the uplink data for postmission 
evaluation or to turn around the data and transmit back to 
the ground via the normal Ku-band tracking data relay 
satellite system link or to use the Ka-band return link of 
the ACTS. 

Link Performance 

The circuit margin calculations for the forward link 
are shown in table 1. There is a 3 dB polarization loss in 
the ACTS/Orbiter link because of the linear polarized 
ACTS antenna and the circular polarized Orbiter antenna. 
The ACTS is operating in a bent-pipe configuration with 
a 900 MHz bandwidth; signal suppression could occur in 
the satellite’s limiter, and a power sharing loss could 
occur in the output power amplifier. However, recent test 
data taken on a prototype ACTS system indicated little or 
no power sharing losses or signal suppression (private 
communications). Accordingly, these losses are zero in 
the calculations. A coding gain of 5 dB for the data is 
used to provide 2.9 dB of link margin for 300 Kbps of 
data. 


Thermal Loading 

Several thermal loading configurations were 
calculated for payloads located in the Orbiter payload 
bay. The analyses were performed using the thermal 
radiation analyzer system (TRASYS) model to produce 
radiation conductors and heating rates for various orbit 
attitudes; the TRASYS output is used as an input for the 
systems improved numerical differencing analyzer model 
to calculate temperatures for 136 nodes (points) within the 
Orbiter payload bay. A payload bay temperature of 
-250°F (113 K) could be achieved with even colder 
temperatures by using thermal isolator between the 
equipment and the payload bay structure. Regardless, a 
small cooling refrigerator will be necessary for the HTSC 
equipment. 

Superconducting Antenna Array 

The use of HTSC materials in antenna designs will 
increase the radiation efficiency of any antenna by 
reducing the ohmic losses in the structure. This appears 
as an increase in the gain of the antenna, since gain and 
radiation efficiency are in direct proportion. The use of 
HTSC materials will have a negligible effect on the shape 
of the antenna radiation pattern. 

Although the gain of all normal-metal antennas can 
be increased to some extent via the use of 
superconductors, mm-wave arrays appear to have the 
greatest potential for practical improvement. For a 
corporate-fed array with a uniform excitation across its 
aperture, the gain of the array is 

G(dB) * 1 0 log(4*A/X2) - a L (3) 

where A is the aperture area, 1 is the wavelength of 
operation, a is the attenuation (dB/unit length), and L is 
the length of the transmission line from the array feed 
point to any radiating element. Figures 3 and 4 show how 
the length of the feed lines increases with greater array 
size and how the feed network losses affect the gain of the 
array, respectively. As can be seen, if losses can be 
neglected (a=0), an arbitrarily large gain can be obtained 
if the physical size of the array is not limited by other 
constraints. However, as the length of the array side 
increases linearly, the length of the path from the array 
feed point to any element increases exponentially. 
Eventually, any losses in the feed network become large 
enough to limit the maximum available gain of the 
structure. These calculations were done at a frequency of 
20 GHz, with lossless radiating elements separated by 1/2 
1. The loss value of 0.25 dB/in. is typical for room- 
temperature CU/PTFE microstrip or stripline transmission 
lines at this frequency. Often, waveguide feed networks 
are used to reduce loss at the expense of physical size. 

Researchers at NASA/LeRC have fabricated and 
tested a 64-element thallium-film superconducting 
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microstrip array operating at 30 GHz. 1 The array is 
fabricated on a 10 m in. lanthanum aluminate substrate, 
and both the radiating elements and the microstrip 
corporate-fed network share the same side of the 
substrate. At 77 K, the device has shown a 2 dB higher 
gain than an identical antenna pattern with gold 
metallization at the same temperature, and 4 dB higher 
gain than the room temperature gold antenna. 

In the antenna described above, both the feed 
network and the radiating elements were fabricated from 
HTSC material. It is known that superconducting patch 
radiators show only a modest increase in efficiency over 
that of normal-metal designs unless the patches are 
fabricated on relatively thin or high-dielectric substrates. 2 
In fact, microstrip patch antennas are usually fabricated 
on thick (~ y20), low dielectric constant (e r < 10), low- 
loss (tand < 0.001) substrates. The substrates that are 


presently compatible with HTSC films do not meet all of 
these criteria. A design, presently under way at JSC, that 
combines a HTSC stripline feed network and normal- 
metal patch radiators fabricated on a relatively thick, low 
dielectric constant substrate, is shown in figure 5. 
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Table 1. ACTS-to-Orbiter Link Calculations (300 Kbps) 


Parameters 

Values 

Remarks 

1. ACTS transmit power, dBW 

16.3 

43 watts 

2. ACTS transmit circuit loss, dB 

-3.0 


3. ACTS transmit antenna gain, dB 

42.0 

1.1m antenna 

4. ACTS transmit EIRP, dBW 

55.3 

Sum 1 thru 3 

5. ACTS power sharing loss due, dB 

0.0 


to 900 MHz bandwidth 

6. Spaceloss, dB 

-210.5 

40744 Km, 

7. Polarization loss, dB 

-3.0 

19.7 GHz 
Linear to Circular 

8. Pointing loss, dB 

-.5 

Estimate 

9. Orbiter antenna receive, 

25.0 

9 subarrays; 

gain, dB 


16 microstrip 

10. Orbiter receive circuit 

-0.5 

patches/sub-array 
HTSC lines to 

loss, dB 


input LNA 

1 1 . Orbiter total receive power, 

-134.2 

Sum 4 thru 10 

dBW 

12. System noise temperature, dBK 

29.6 

NF - 5 dB, 

13. Noise spectral density (No) 

-228.6 

T a « 290 K 
Boltzmann’s 

14. Received C/No, dBHz 

64.8 

Constant 

dB/KHz 

Lines 11 - (12+13) 

15. Bit rate bandwidth, dBHz 

54.8 

300 Kbps 

16. Received S/N, dB 

10.0 

Lines 14-15 

17. Theoretical required S/N, dB 

9.6 

1.E-5BER 

18. Coding gain 

5.0 

(R « 1/2, 

19. Implementation loss, dB 

-1.5 

K* 7) 
Estimate 

20. Demodulation loss, dB 

-1.0 

Estimate 

21. Required S/N, dB 

7.1 

Lines 17 - 

22. Link circuit margin, dB 

2.9 

(18+19+20) 
Lines 16-21 
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Figure 3. Feed Network Complexity Increases Exponentially as 
Corporate-Fed Array Side Length Increases Linearly. 
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Figure 4. Array Gain Versus Size as a Function of Feed Line Losses. 


49 


Space Systems Technology 




Clamp 


Cavity 


Patch Aperture 


Plexiglas Radome/Clamp 


K Connector 


Patch Substrate 




Figure 5. Single Aperture-Coupled Patch Antenna and Test Fixture - Cross Section. 



Space Systems Technology 


50 




Computer Antenna Pointing for Space Station Freedom 


G. Dickey Arndt and Brian Bourgeois* 
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Abstract 


Theoretical Development 


A Kalman filter, using rate gyro information from the 
Space Station Freedom high-gain antenna and observation 
unit pointing vector to target satellite, is introduced to 
compensate for pointing errors due to structural 
oscillations of the long, flexible boom on which the 
antenna is mounted. 


Introduction 

The proposed design of Space Station Freedom (SSF) 
places its high-gain antenna (HGA) on a long, flexible 
tower. This introduces the possibility of antenna pointing 
errors due to structural oscillations of the tower. Our 
solution to the problem consists of mounting a rate gyro 
assembly (RGA) on the HGA base and using RGA output 
and software to compensate for the structural dynamics. 

A detailed description of the concept is given below, but 
the basic idea is as follows. Guidance, navigation, and 
control (GNC) provides, at periodic intervals, the position 
vectors of SSF and the target tracking data and relay 
system (TDRS) satellite. Were the tower rigid, this 
information would suffice to point the antenna (open-loop 
pointing). Because of oscillations of the tower, however, 
the pointing vector computed from GNC differs from the 
actual pointing vector to the target. The two vectors are 
related by a linear transformation, which is computed by 
using the rate gyro information and is improved by using 
the observed pointing vector while the antenna is locked 
on the target. 

A computer simulation was implemented to 
demonstrate proof of concept. In the program, the HGA 
is modeled as a 6-ft diameter parabolic dish that radiates 
in the Ku-band. The flexible tower has a total length of 
about 10 ft. Gaussian noise on the measurements of the 
antenna gimbal angles, and rate gyros are taken into 
account. The pointing accuracy goal for this design was 
chosen to be one-half of the 3-dB beamwidth, or 
approximately 6 milliradians (mrad). The simulation 
results demonstrate that this objective can be met. 

The idea of mounting an antenna on a long, flexible 
boom is a novel one that has not been attempted. To the 
best of our knowledge, literature on this topic is 
nonexistent. J. Suddath determined that there is indeed a 
potential pointing problem and gave a preliminary 
analysis of a possible solution. 1 The present work is an 
outgrowth of those seminal ideas. 


At periodic time intervals, GNC provides the unit 
pointing vector u from antenna to target. The vector u is 
the pointing vector measured in the inertial frame and 
then transformed to the coordinate frame of the known 
SSF orbit, denoted here as the orbital frame. The 
translational motion of the orbital frame is that of the SSF 
orbit. The rotational motion of the orbital frame is about 
the axis perpendicular to the plane of the SSF orbit with 
constant angular velocity equal to that of SSF. In this 
coordinate frame, the x-axis is always parallel to the 
radial vector from Earth to SSF. Because of the random 
oscillations of the tower, the antenna coordinate frame 
differs from the orbital frame. Failure to account for this 
may result in severe pointing errors. One approach is to 
calculate the transformation R from the orbital frame to 
the antenna frame; that is, 

a s Ru, 


where 

a = unit pointing vector in antenna frame 
u = unit pointing vector in orbital frame. 

Because of the large distances involved, we may 
ignore translational motion and assume that R is purely 
rotational. It is well known 2 that R is an orthogonal 
matrix; that is, RR* = I, where I is the identity matrix and 
where R* is the transpose of R. Also, the set of 
orthogonal matrices (that preserve orientation) is a 3- 
dimensional space; that is, it can be parametrized by three 
variables. We use the Euler angles (<|>,0,tp) 2 and write 


R- 


f cos0 simp 

- cos+ simp + sin+ sinO cosip 
^ sin+ simp + co$4 sinO cosip 


cosd simp 

cos+ cosip + sin+ sin6 simp 
- sin+ cosip + cos4 sinO simp 


-sinO > 
sin+ cosO 
cos+cosO/. 


Here, 

<(> - the perturbation angle of rotation about the axis in 
the plane of the SSF orbit, which is parallel to the 
radial vector to the Earth 

6 - the perturbation angle of rotation about the axis in 
the plane of the SSF orbit, which is parallel to the 
radial vector to the Earth 
ip - the perturbation angle of rotation about the axis 
perpendicular to the plane of the SSF orbit. 

Let x = («j»,0,\p) represent the state vector, an 
unknown function of time to be determined to calculate 
the transformation R. We now develop a system of 
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ordinary differential equations satisfied by the 
components of the state vector. 

Rate gyros at the base of the antenna provide the 
instantaneous angular velocity vector w of the antenna 
frame. The w is related to the time derivative of the state 
vector of Euler angles x* = (<t>*,0 , ,q>*) by 



w 


' 1 0 -sin0 ' 



0) - 

(Oy 

K 

0 cos<|> sin<j> cos0 


9' 




^ 0 -sin<j> cos<(> cos0^ 




A = A(x) can be inverted to give 

x 9 = A-l(x) a) = f(x,u)> 


with 


A-l(x)x 


sin<|> tan0 

COS(J> 

sin<(> sec0 


\ 

cos<|> tan0 
-sin <(> 

cos<(> sec0 


This is a nonlinear system of three ordinary 
differential equations, which, from given initial 
conditions, determines the state of Euler angles and, 
hence, the orthogonal transformation R from inertial to 
antenna coordinate systems for all time. In components, 
the system can be written 


* o x + coy sin(j> tan0 + o> z cos<J> tan0 
0' * o)ycos<j> - o) z sin(j) 
x|>' » (o y sin<|) see© + o> z cos<|> sec0. 

This system of equations serves as the state 
propagator in a Kalman filter which, along with the 
observation of the unit pointing vector a in the antenna 
coordinate frame, provides a best estimate of the state at 
time t + Dt, given a best estimate of the state at time t. 

Results and Conclusions 


One scenario envisioned for using the concept 
discussed in this paper is the following. The SSF HGA is 
locked onto the target TORS satellite for one-half of its 
orbit around the Earth; that is, for approximately 
46.5 min. The antenna is out of contact with TORS for 
the other half of the orbit. When it comes back out of the 
Earth shadow, contact must be reestablished. 

GNC will inform SSF where to point the antenna, 
giving the pointing vector u discussed above. The SSF 
onboard computer will use the best estimate of the state x 
of Euler angles to calculate the transformation R, which 
will be applied to u to give the unit pointing vector a in 
the antenna frame of reference. The antenna gimbal 
angles will be adjusted to point in this direction. If the 
pointing error is within the design goal of 6 mrad, which 
is one-half the 3-dB beamwidth of the HGA, the antenna 


should be able to lock on the target. If acquisition is 
unable to be established, a scanning mode is entered. In 
this case, the scanning procedure should be much simpler 
than if the antenna were pointed using the GNC vector u. 

A computer program was implemented to simulate 
this scenario. The three Euler angles were given arbitrary 
initial phases, representing the point in time at which SSF 
has just moved from behind the Earth shadow and into the 
view of the TORS satellite. It is assumed that target 
acquisition has been accomplished by unspecified means. 
For 46.5 min, the state vector x is propagated and updated 
using observations of the actual pointing vector. For the 
next 46.5 min (in the shadow of the Earth), x is 
propagated only, assuming no observations of the actual 
pointing vector. When this is completed, a calculation of 
the pointing error is made and is compared with the 
pointing error that would be obtained using only the GNC 
vector u. 

The results of the simulation indicate that the 6 mrad 
pointing error goal can be met, provided that noise on the 
measurement of the antenna gimbal angles and of the 
tower angular perturbation rates is not too significant. 
Tolerable noise levels are 2 mrad for the gimbal angles 
and 10 deg/hr (0.05 mrad/s) for the rate gyros. Improved 
noise levels result in improved system performance. An 
increase in rate gyro sampling frequency also results in a 
decrease in antenna pointing error. 

The pointing error was observed to be a rapidly 
oscillating function of time with a frequency of 
approximately 1 Hz, reflecting the simulated frequency of 
the tower oscillations. With a sampling frequency of 
80 Hz, the mean pointing error was approximately 
1.5 mrad with a maximum of 3.5 mrad over the 93 min 
orbit and with a given 30 mrad initial error. A sampling 
frequency of 120 Hz reduced the mean pointing error to 
approximately 1 mrad with a maximum of 2.25 mrad 
under the same conditions. 

In conclusion, the study shows that the concept of 
using rate gyro information for propagation with observed 
pointing information for improvement to aid in target 
reacquisition is a viable one. The concept has potential 
applications to SSF or to any large space vehicle where an 
HGA must be positioned at some minimum distance from 
the vehicle to avoid interference during reception and 
damage to onboard electronics during transmission. One 
such application for this technology is to the proposed 
onboard orbital debris radar antenna. One use of this 
radar is as a last resort warning signal that SSF is in 
imminent danger of collision with a debris particle. The 
decision as to whether or not to execute a costly maneuver 
may depend crucially on the accuracy of the radar 
measurement. The techniques espoused in this paper 
provide an aid to obtaining the required accuracy. 
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Figure 1. Pointing Error Versus Time (Sampling Frequency = 80 Hz). 
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Abstract 

A communications link between the Space Shuttle 
Orbiter and the advanced communications technology 
satellite is described. The prime objectives are to 
demonstrate a Ka-band low-Earth orbit to geostationary 
orbit (LEO-GEO) link as well as to provide a test-bed for 
a high-definition television video compressor. Both 20 
and 30 GHz hardware for the experiment have been 
breadboarded, including a 144-element, circularly 
polarized phased array antenna and a 1-W hybrid power 
amplifier, both at 29.S GHz. 

Introduction 

A Ka-band, mobile communications link between the 
Space Shuttle Orbiter and the advanced communications 
technology satellite (ACTS) has been proposed as a joint 
effort of JSC, Jet Propulsion Laboratory, and Honeywell, 

Inc. The Orbiter will communicate with JSC by low bit- 
rate, convolutional encoded data. A compressed, high- 
definition television (HDTV) signal constitutes the 
source. 

The objective for the Orbiter/ACTS flight experiment 
(OAFE) is several-fold. First, the experiment will 
demonstrate the utility of ACTS technology in future 
commercial LEO-GEO satellite relays. Second, the 
experiment will serve as a test-bed for an HDTV 
compression algorithm developed by Honeywell, Inc. 

Also, monolithic microwave integrated circuit (MMIQ 
and Ka-band hybrid solid-state technologies used in the 
transmitter will further advance the application of these 
technologies in a space environment. Future satellite 
systems expanding on ACTS technology would benefit 
greatly by extended use of MMICs, which are often 
regarded as unproved in a space environment. Other 
objectives of the experiment are to evaluate a moderate 
gain antenna using computer steering in the dynamic 
environment of a maneuvering Orbiter and to evaluate 
multi-beam communication links for direct distribution of 
experiment data for manned space applications. 

The OAFE definition has been modified several 
times as a result of budgetary constraints. This paper will 
address the hardware as it was originally conceived and 
developed for the experiment: a return link, transmitting 
from the Orbiter to JSC via the ACTS satellite. Most of 
this hardware will be used in the revised experiment (a 
ground-ACTS-ground propagation study).Pww*Wj#r** ^ 



Orbiter/OAFE: Return Link 

This version of the OAFE was conceived as a return 
link from the Orbiter to JSC via the ACTS satellite. Low 
bit-rate data are radiated through a phased array antenna 
to the ACTS 1-m steerable antenna. The ACTS, 
configured in the microwave switch matrix mode, relays 
the signal to JSC, where the signal is received by a 1.2-m 
dish antenna. 

Link Performance 

A 4.32 dB link margin exists for the return link 
experiment. The phased array consists of 9 subarrays, 
each driven by a 1-W amplifier, to provide a transmit 
power of approximately 9 dBW. With an array antenna 
gain of 25 dBi and circuit losses totaling 2 dB, the EIRP 
is 32 dBWi. 

The received signal is demodulated by a long phase- 
locked loop with 2.5 dB implementation/demodulation 
loss. A 5.0 dB coding gain is necessary to close the loop 
with a 4.3 dB margin for a bit rate of 16 kbps. The link 
margin is determined primarily by the uplink (Orbiter to 
ACTS) since the gain of the ACTS 1-m antenna is 
considerably less than that of the isolated spot beams. 

Antenna and Doppler Considerations 

The ACTS 1-m steerable antenna will have an 
instantaneous maximum angular rate of 0.20 mrad/sec 
when tracking the Orbiter. The Doppler shift and Doppler 
rates reach a maxima of ±750 kHz and ±1 kHz/sec, 
respectively. Since the Doppler profile is well known, the 
shift is readily precompensated. 

The onboard phased array receives pointing data 
from the Orbiter guidance, navigation, and control 
(GN&C) to determine the phase shifter bits. The Orbiter 
payload bay is pointed to the ACTS within 10°, and the 
array points, open-loop, to ±8° in steps of 1.3° (element 
spacing = 0.7 1). 

Flight Hardware 

A block diagram of the transmitter for the OAFE 
return link is shown in figure 1. Audio data at 16 kbps is 
rate 1/2 convolutionally encoded. The signal is biphase 
shift keying (BPSK) modulated and upconverted to 
.5 GHz. A more recent design allows for Doppler 
WOT FfLIVfEh 
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precompensation by replacing the BPSK modulator with a 
direct digital synthesizer. Although the receiver is 
capable of tracking through the ±750 kHz of Doppler 
shift, precompensation allows for a narrower noise 
bandwidth in the receiver. 

The 29.5 GHz signal is preamplified before a 9-way 
power divider routes the signal to nine subarrays. Each 
subarray is preceded by a 1-W phase shift/amplifier 
module. The phase shifter is a 4-bit MMIC developed by 
Honeywell. Input power to each module is +12 dBm. A 
10 dB insertion loss associated with the phase shifter and 
30 dB of amplifier gain results in 1 W being delivered to 
each subarray. 

Ka-Band Antenna Array 

The transmitting antenna at 29.5 GHz consists of a 
144-element circularly polarized microstrip phased array 
arranged as a 3x3 array of 16-element subarrays. Each 
subarray consists of a 2x2 array of a 4-element cluster 
designed as a single feed, circularly polarized microstrip 
compound radiating element. One version of the 
4-element cluster is shown in figure 2. A 4-bit phase 
shifter in each of the 3x3 arrays will provide electronic 
scanning in a conical space of approximately 10*. 

This design of the compound radiating element 
employs dual-feed, square microstrip patch elements in 
conjunction with sequential feeding and rotation 
technique to enhance the axial ratio bandwidth. 

Impedance and axial ratio bandwidths of over 1 GHz at 
the center frequency of 29.5 GHz are very easily 
achieved. The typical radiation pattern of the 16-element 
subarray (fig. 3a) consisting of a 2x2 array of the 4- 
element cluster is shown in figure 3b. 

The wide bandwidth for this version comes at the 
expense of a small loss in the subarray gain. For this 
particular experiment, the bandwidth required is less than 
200 MHz. This will permit us to use a more efficient 
version where single feed, structurally perturbed square 
microstrips are used to design the 4-element cluster. The 
receiving antenna at 19.78 GHz is a similar 144-element, 
circularly polarized microstrip phased array antenna. 

Phase Shift/Power Amplifier Module (PSPA) 
Mechanical 

The prototype phase shift/power amplifier (PSPA) 
module is shown in figure 4. 

The second revision is similar in form, although 
shorter, and was designed with a mating heat sink. This 
unit has dimensions 7.0 in. x 1.1 in. x 1.1 in. (not 
including the heatsink). 

The PSPA module shown in figure 4 is, in form, an 
identical predecessor to a flight unit with the exception of 
the flange on the input side. This flange would be absent 
on the flight unit to allow for a front-loading array 
structure. For ground use, the dual flange is a convenient 
method of locking the module in a heat sink. The final 


revision is shown in figure 5 inside a mating heat sink 
designed for ground use. 

Both ends of the module have a K-connector 
interface that accepts either a two-hole flange SMA 
female or flush mount female-female interconnect. The 
SMA female connector is used on the output for lab 
testing, while in operation a 1.1 in. x 1.1 in. x 0.25 in. 
antenna carrier plate mounts flush onto the PSPA flange. 
In addition to the K-connector interface, a miniature D- 
connector resides on the input side. The D-connector 
accepts regulated power at +12V and -5V as well as 
4 transistor-transistor logic phase shift bits. 

Voltage regulation for the PSPA resides in a recess in 
the heat sink. The heat sink also mounts a 1.2 W 
miniature fan over the output side of the PSPA. The fan 
draws 5.30 ft 3 of air per min along the sides of the PSPA 
module and through holes between the bottom heat sink 
fins. An additional air channel runs aft to the regulator 
compartment. 

Electrical 

The design specifications of the PSPA are as follows: 

Gain 30 dB 

1 dB compression 30 dBm 

Bandwidth 2 500 MHz 

Harmonic Distortion TBD 

Prime DC Power * 30 W 

The PSPA is comprised of a 4-bit MMIC phase 
shifter followed by eight hybrid metal semiconductor 
field-effect transistor (Toshiba™ ) stages. The first 
prototype PSPA exhibited gain in excess of 30 dB at 1 W 
of output power. However, the driving stages were 
narrowly tuned for gain above 6 dB, which proved to be 
too thermally sensitive. The prototype is being refitted 
with stages matched for broader bandwidth. Also, to 
increase reliability, the second revision PSPA has been 
designed to operate at a lower temperature. 

Ground Station 

A 19.78 GHz superheterodyne receiver (fig. 6) is 
being developed for the JSC ground station. An existing 
MMIC 20 GHz receiver developed by Harris Corporation 
will be used to downconvert the signal to 3.58 GHz. A 
long phase locked loop will track the Doppler shift to 
maintain a constant IF of 70 MHz. The quadrature phase 
detector then demodulates and produces the voltage 
controlled crystal oscillator (VCXO) control voltage. The 
demodulated data are then input into an ASIC bit 
synchronizer to establish a clock and recover the data. 
Finally, the data are decoded. To improve acquisition 
time, the VCXO is swept when the loop is not phase 
locked. The acquisition time, without Doppler 
compensation, is approximately 3.5 sec. 

With the current BPSK system, performance is 
degraded by the phase jitter produced by the phase noise 
of the ACTS local oscillators. Figure 8 shows the effect 
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of phase jitter on bit error rate performance. 1 The 
minimum calculated root mean square phase jitter for the 
experiment is 11.4 s , which results in a degradation of 3 
dB. A study is currently being performed to determine 
whether differential phase shift keying (DPSK) will 
improve system performance. DPSK has a greater 
immunity to phase jitter, but is not as efficient as BPSK. 2 
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Figure 1. OAFE Transmitter. 
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Figure 4. The Prototype Phase Shift/Power Amplifier (PSPA) Module. 



Figure 5. The Final Revision of the PSPA Inside a Mating Heat Sink. 
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Hybrid Vision’s Eye Tracking 


Richard D. Juday 
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Abstract 

The Johnson Space Center Hybrid Vision Program is 
developing hardware for a medical purpose. It is a high- 
speed image processing device, an optical joint Fourier 
transform correlator, that JSC has patented for use in 
retinal laser treatment. 

Introduction 

The Hybrid Vision Program at the Johnson Space 
Center combines optical and digital image processing for 
various purposes. Among the optical processing elements 
under development are optical correlators, spatial light 
modulators, and optimal filter theory. Among digital 
processing elements are digital stereo, video rate 
geometric image warping, and space variant image 
sensing. One method we recently patented 1 * 4 is a method 
of processing an unmodeled image of a surface so that the 
apparent motion of the surface can be rapidly tracked. 

The effect as seen from the sensor is that the surface is 
stabilized. Its potential space applications include 
navigation for autonomous planetary landing, detection of 
previously unmodeled landing hazards, and autonomous 
rendezvous and capture. We are also pursuing Earth- 
bound applications for our techniques, significantly in 
human vision. Two such are most significant. Hie first is 
prosthetic image warping for field defect problems such 
as maculopathy and retinitis pigmentosa, a program we 
have active among NASA, the University of Houston, and 
the University of Pennsylvania. The second is surface 
tracking by means of the optical joint Fourier transform, 
as described above, for tracking the motion of surface 
features. We have patented its application to tracking the 
motion of the retina for use in laser photocoagulation of 
diseased retinal structures. In this application, we have 
allied ourselves formally with the Army’s Missile 
Command (MICOM) and with Pinnacle Imaging. The 
military is interested in developing a passive 
identification system that would be able to quickly 
identify friend or foe and thereby reduce fratricide in 
battlefield situations. MICOM is contributing funding 
and practical correlator technology. 5,4 Pinnacle is 
supplying a test-bed for the concept described in the next 
section. Figure 1 is reproduced from the patent. 

Problem Statement/Description 

The need for the image stabilization method arose in 
the need to land an autonomous vehicle on a planetary 


surface in the presence of unknown obstructions. JSC 
proposed image stabilization based on the optical joint 
Fourier transform and led a proposal, including Ames 
Research Center and the Jet Propulsion Laboratory (JPL), 
for the development of a highly sophisticated vision 
system. It would fully model the visible obstructions 
based on optic flow, the differing motions of elements in 
the field of view as the viewpoint translated. The joint 
transform correlator (JTC) would provide the gross 
tracking, and the digital image processing modules 
developed by Ames and verified by JPL would analyze 
the second-order image motion for the underlying 
3-dimensional basis. Although the fully competent vision 
system was not funded, the various pieces continue in 
separate development, including the joint transform 
correlation stabilization. Juday described the image 
analysis method to the University of Alabama’s H. John 
Caulfield, who knew of a medical practitioner who had 
need of the technique. Caulfield put Juday in touch with 
Steve Charles of Pinnacle Imaging, and the project is now 
under way. In the retinal laser treatment, there is a need 
for landing the laser onto only the desired portions of the 
retina. 

Approach/Method 

The method of the bptical joint Fourier transform 1 * 4 
offers a fast, reliable, and inexpensive method to correlate 
images with reference images. In the medical field, the 
laser eye surgeon needs rapid registration of retinal 
images to facilitate hitting exactly the spot on the retina 
that the surgeon wishes to photocoagulate. Pinnacle 
Imaging has shown the medical practicality of a digital 
method for rapid registration; however, the digital method 
is too expensive for commercialization. The optical 
image processing method using the joint Fourier 
transform correlation promises to be sufficiently 
inexpensive to be commercially attractive. The digital 
method was technically confounded by torsion of the 
eye — a problem JSC thinks can be solved by digital 
processing of the reference image. 7 

JSC developed the JTC method of image stabilization 
for automated planetary applications, notably the 
extraction of shape-from-motion owing to translation of 
the sensing platform with respect to a 3-dimensional 
structure. Hie JTC method can remove the image motion 
that originates in camera position jitter, rather than in 
differing perspective points on the object, and thus is 
regarded as noise to the process. The method has been 
substantiated in laboratory measurements. 24 
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Results 

Significantly, Rocketdyne (a division of Rockwell 
International) has presented results* in which their 
prototype of an eye surgery JTC met the system 
requirements for speed, linearity, capture radius, etc. 

Draft specifications for the processing speed and latency 
are shown in figure 2. The prototype ran at 700 Hz with a 
lag time from conclusion of electronic image to provision 
of error signal of just over 2.5 msec. Our medical partner, 
Pinnacle Imaging, has formed a technical alliance with 
OCA Applied Optics to construct the optical processor of 
a surgical system that would embed the JTC technology 
to track the retina. 

Conclusions 

The technique is proven in the laboratory and in 
prototype. Organizations have committed to 
implementing the method in practice and appropriate 
actions are being taken. 
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Figure 1. Optical Joint Correlator for Real-Time Image Tracking and Retinal Surgery. 
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Input image format and system timing diagram... joint transform correlation for eye tracking 
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Figure 2. Example Timing Diagram as Necessary for Retinal Tracking for Photocoagulation. 
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Abstract 

A joint NASA Dryden Flight Research Facility/JSC 
program is being conducted to determine the feasibility of 
an automatic recovery of a spacecraft using a ram-air 
inflated parafoil recovery system for the final stages of 
entry from space. The feasibility was studied using a 
150 lb model of a flat-bottomed biconic spacecraft flown 
with a man-rated parafoil. Key elements of the vehicle 
include global positioning system navigation, a flight 
control computer, sonar sensing for terminal altitude, and 
onboard data recording. A flight test program was used to 
develop and refine the vehicle. Development included 
several ground tests and manual flight using a radio 
uplink. The vehicle demonstrated automatic flight from 
8,000 ft above ground level and a 1-mile lateral offset that 
resulted in a precision flared landing at a predetermined 
spot. Test results and future program objectives are also 
discussed in this paper. 

Introduction 

NASA is currently studying a variety of vehicles for 
the return of humans and cargo from space. Although the 
configuration of these vehicles is not yet confirmed, a 
number of capsule shapes are currently under 
consideration for several proposed NASA missions. 
Among them are the assured crew return vehicle (ACRV), 
which will be a “lifeboat” for the Space Station Freedom. 
The Lunar Transportation System (LTS) is an element of 
the Space Exploration Initiative (SEI) that will transport 
crewmembers to the lunar surface and return them to 
Earth. The Mars Environmental Survey is an SEI 
precursor mission that will map portions of the surface of 
Mars. The Personnel Launch System and Lifesat mission 
will return crewmembers and biological experiments from 
low-Earth orbit. 

Several approaches are being considered for landing 
and recovery of advanced spacecraft. The ACRV mission 
is currently studying both land and water landing options, 
using parachutes and a landing attenuation system. The 
LTS study managers have baselined land landing to 
provide operational flexibility. For a capsule vehicle, all 
of the above named missions could benefit from the use 
of a deployable precision landing system. 

Problem Description 

The use of deployable ram-air inflated gliding 
parachutes for spacecraft recovery has been proposed 
since the mid-1960s. Studies for the Gemini and Apollo 


Programs included the use of Parasails, Sailwing, and 
Rogallo Parawings for spacecraft recovery. The primary 
problems with these systems were inflation performance 
and reliability. While the performance of these systems 
was promising, the lack of a large experience base hurt 
chances for their use in a large recovery program. An 
inability to control the high horizontal velocities 
developed during flight also made these systems 
unacceptable. The emergence of the ram-air inflated 
Parafoil as the parachute of choice among sport jumpers 
has brought the issue of gliding parachutes for spacecraft 
recovery back to the forefront. 

The Advanced Recovery Systems Program, managed 
out of the NASA Marshall Space Flight Center, focused 
on the development of a large-scale gliding recovery 
system. Although canceled after nine flight tests, the 
program was successful in developing a unique inflation 
loads management system for large Parafoils. Reliability 
issues that raised concerns during the 1960s have been 
reduced because of the high number of systems in sport 
use today. The major issue that remains with the use of 
these systems is the development of a highly reliable, 
autonomous landing flare system. Engineers at NASA 
Dryden Flight Research Center, under the sponsorship of 
JSC, have been flight testing a system that uses global 
positioning system (GPS) guidance and a sonar altimeter 
to perform this task. 

The purpose of this paper is to summarize the results 
of phase 1 of the Spacecraft Autoland project. A 
description of the vehicle, its design, and control concepts 
are presented. The steps leading to the final flight 
demonstration are detailed. The flight results, lessons 
learned, and a sample of the flight data are included. 
Future program objectives are also included. 

Potential customers for this technology within NASA 
include all of the manned space programs listed above as 
well as unmanned vehicles, including planetary probes 
and booster recovery systems. Potential customers for 
this technology outside of NASA include the U.S. Navy, 
who is studying the use of automatic gliding parachute 
systems on aircraft ejection seats, and the U.S. Army/Air 
Force, who prefer offset delivery of cargo to minimize 
danger to aircraft and crews of the airlift community. 

Approach/Method 
Vehicle Description 

The philosophy adopted for this project was to use 
off-the-shelf equipment whenever possible to keep costs 
low and reduce development time. The flight test article 
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consisted of a flat-bottomed biconic vehicle, flight control 
system, and a Parafoil recovery system. The biconic 
vehicle was constructed of tubular steel with a plywood 
bottom and removable aluminum upper and side skins. 
The Parafoil used for this phase is a 288-ft 2 wing built by 
Glide Path Company (model name, Manta™ ). The docile 
flight characteristics, low wing loading (near 0.5 psf), and 
proven design allowed the project to concentrate on the 
development of the autonomous flight system rather than 
the parachute itself. The project concept was to substitute 
a smaller, higher performance (higher wing loading) 
Parafoil once the vehicle is developed. The flight vehicle, 
parachute, and harness are depicted in figure 1. 

The flight control system consisted of both manual 
and autonomous modes. The vehicle was controlled 
using two control line actuators to perform turns and the 
landing flare maneuver. The control actuators, widely 
used in unmanned air vehicle systems, provide 13.75 ft-Ib 
of torque. 

The manual mode used a radio control model receiver 
and transmitter to uplink signals through a 15 W power 
booster. This mode was used primarily in the early stages 
of the program to develop confidence in the deployment 
and flight characteristics of the vehicle. 

The autonomous mode was the primary mode used 
for the demonstration flight program and allowed the 
vehicle to guide itself back to the programmed target 
using GPS data for navigation. 

The following hardware items were included as part 
of the autonomous system: 

Hardware item Use 

Sensym SMRTBAR01 Pressure Altimeter Approach guidance waypoints 

Polaroid Ultrasonic 6500 Sonar Altimeter Landing Flare maneuver 

Rockwell NavCore V GPS Receiver Navigation 

KVH C100 Magnetic Compass Vehicle Heading 

Eight Computer (Custom) Eight Systems Processing 

Ground Tests 

A ground test approach was used to verify the 
performance and operation of the autonomous flight 
system hardware. A pickup truck and a fixed crane were 
used in two different test series to verify the steering 
control commands from the flight systems, the operation 
of the GPS receiver, and the performance of the sonar 
altimeter. 

Validation of the steering commands was performed 
by placing the flight vehicle in the bed of a pickup truck 
and driving the vehicle over a surveyed course on the 
Edwards Air Force Base dry lakebed. After acquiring 
lakebed landing site coordinates into memory, the truck 
would be driven several thousand feet away at a speed 
similar to that of the vehicle in flight (20 mph). An 
observer riding in the truck would then translate the 
vehicle actuator position into a left or right turn for the 


driver. This proved to be an effective way to obtain a 
crude zero-wind simulation of the operation of the GPS 
receiver and flight control computer. 

A second ground test series used a crane to check the 
functionality of the sonar altimeter. The original vehicle 
concept involved downlinking the control computer data 
display to a ground-based video monitor. It was 
discovered, however, that the video downlink degraded 
the sonar altimeter range from 35 ft down to about 20 ft 
above ground level (AGL). Since a range of about 30 ft 
was needed, many variations of transmitter and antenna 
location were evaluated by hoisting the vehicle by crane 
to a height of 35 ft. After some limited success, we 
decided to eliminate the downlink and record the video 
signal on board. After this change was made, the crane 
was used to verify the operation of the altimeter. 

Flight Tests 

Numerous steps were taken toward the final 
demonstration of autonomous flight. Flight tests 
performed to demonstrate the vehicle capability included 
“slope soaring” and airdrop flights. 

Early in the development, the vehicle was flown 
manually with only the uplink receiver and control servos 
installed. The first manual mode flights consisted of 
“slope soaring” the vehicle from a hillside in times of 
high winds (approximately 15 kn). These flights occurred 
prior to the development of the test-bed vehicle and 
provided a method for flying the vehicle without first 
having to validate parachute and harness deployment 
characteristics. Two flights were made with this 
technique and were used to evaluate with the general 
flight characteristics (including gentle turns), the landing 
flare, and control actuator capabilities. 

To initially validate the parachute deployment and 
harness design, a second wedge vehicle was fabricated 
with the same external geometry and weight as the flight 
test vehicle. This test-bed was constructed at low cost 
and was considered expendable because it did not contain 
any internal electronics. The vehicle was airlaunched 
several times, and the data produced provided significant 
confidence in the parachute deployment and harness 
design. 

The autonomous (auto) flight mode could be selected 
from the ground transmitter. The vehicle typically would 
remain in the auto mode until it failed to perform as 
desired. Problems with the control logic were common 
during the early auto mode flights as several control 
algorithms were evaluated. To have the capability for 
immediate reversion to manual mode was considered 
mandatory. While in auto mode, the vehicle turn 
performance, navigation, and landing flare were 
evaluated. The height at which the flare maneuver was 
performed and turn performance parameters were often 
adjusted between flights. 
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Flight Operations 

The majority of the flight tests were performed 
using a Cessna C206 aircraft with side door. After the 
completion of all flight checklists, the vehicle landing 
location and ground wind speed and direction were loaded 
into the flight computer. Prior to loading into the aircraft, 
GPS lock was achieved using the vehicle-mounted GPS 
antenna. The vehicle was then loaded into the aircraft and 
connected to the external (aircraft-mounted) GPS antenna. 
During launch, an umbilical cord was separated, and the 
vehicle was switched over to the vehicle-mounted antenna 
via an internal switch. The external GPS antenna was 
removed after Flight 22 (see Results). Following a 
successful launch and parachute deployment, it was 
necessary to manually command full brakes to release the 
control lines. Left and right turns would be performed to 
verify free controls and generally check the health of the 
system. Approximately 1 min after launch, the auto mode 
was selected. 

The auto mode approach consisted of a direct 
approach to the landing site, loiter above the target, j-tum 
to final approach, and the landing flare. The geometry of 
the landing maneuver is included in figure 2. The first 
phase begins at the initiation of the auto mode, 
commanding the vehicle at a constant heading toward the 
target. At a point called waypoint 1 (WP1), the vehicle 
transitions to a loiter, during which the vehicle flies in an 
oval pattern until reaching an altitude A2 (300 ft). The 
initiation of the second turn in the loiter oval is called 
WP2. At the altitude A2, the vehicle flies downwind and 
transitions to the j-tum at WP4. The vehicle begins its 
final approach at 100 ft AGL. The sonar altimeter begins 
operation at about 35 ft AGL, and the flare maneuver is 
initiated approximately 25 ft AGL. 

Results 

A series of eight flights was performed in the auto 
mode during November and December 1992. The flight 
numbering system began at Flight 1 with the “slope 
soaring” tests. The auto mode tests are numbers 20 
through 28. A summary of each of the tests is included 
below. 

Flight 20 11/19/92 The vehicle was launched 
downwind of the target, and once GPS position was 
locked in, the vehicle performed several “figure 8” 
maneuvers. It appeared that the vehicle was having 
difficulty acquiring or maintaining a track to the landing 
site. The vehicle was then switched back to manual mode 
for the remainder of the flight, including the landing. 
Discussion with skydivers who had made jumps a few 
minutes later indicated the presence of high winds at 
altitudes above 2000 ft AGL. At the higher altitudes, the 
vehicle ground track was near stationary. This lack of a 
pronounced ground track confused the flight software 
because the velocity relative to the ground was nearly 
zero or negative. 


Flight 21 11/24/92 This launch was again to the 
downwind side of the target, and the winds at altitude 
appeared low, judging by the lack of wind turbine activity 
at nearby Mojave. When put into the auto mode, the 
vehicle again performed the “figure 8” maneuvers as on 
Flight 20. The vehicle was then flown to the final 
approach in manual mode and returned to auto to perform 
the landing flare. Shortly before touchdown, the vehicle 
flew over a 5-ft deep ditch, which affected the final flare 
logic. The final rate of descent at touchdown was 
measured at 3.5 ft/s. 

Flight 22 11/24/92 Upon loading the vehicle into the 
launch aircraft, a problem was discovered with the 
external (airplane mounted) GPS antenna. After some 
diagnostic checking and discussion, it was decided to fly 
without the use of this antenna. As a result of this 
problem, launch did not occur until 55 min after the wind 
information was programmed into the flight computer (as 
a point of comparison, the time between wind loading and 
flight is normally about 15 min). During this time, the 
wind direction changed and resulted in a 5-kn downwind 
landing. Launch was performed upwind of the target, and 
the vehicle was flown manually for approximately 90 sec 
to ensure good GPS lock and to establish a ground track 
prior to auto mode initiation. In auto mode, there were no 
“figure 8” maneuvers, and the vehicle remained in auto 
mode for the remainder of the flight. Several good 
holding patterns were flown. The landing was a bit 
harder, similar to a downwind landing in an aircraft. 
Postflight review of the data indicates that GPS lock was 
achieved about 45 sec after launch, compared with 35 sec 
on Flight 21 in which an external GPS antenna was used. 
Thus, it was decided to remove the external GPS antenna 
from the launch aircraft. 

Flight 23 12/2/92 This flight was landed in the auto 
mode in the open desert. The landing flare maneuver was 
initiated at 25 ft AGL and was performed nearly perfectly 
with a vertical velocity near zero. It was noted that 
landings on the uneven desert surface produced 
significant scatter in the sonar altimeter readings. 

Flight 24 12/2/92 This flight was landed on a 
smooth surface in the manual mode, with partial brakes, 
but no final flare. During Flights 23 and 24, ground 
winds were near zero, but the upper altitude winds were 
significant. This caused the navigation logic to input 
spurious maneuvers, including the “figure 8” maneuvers 
seen previously. The results of these two flights 
prompted the team to update the flight control system to 
hold magnetic heading whenever the GPS and magnetic 
compass readings differ by more than 45 deg. 

Flight 25 12/10/92 This flight was a test of the 
software modification discussed above. The software 
gains were reduced on the navigation turns (“baby turns”) 
and were increased on the large maneuvering turns. The 
oscillations were eliminated on this flight; however, the 
navigation turns were reduced too much, causing heading 
changes that took too long to return the vehicle to the 
desired heading. Also, the maneuvering turns resulted in 
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270 deg turns being required to accomplish a 180 deg 
heading change. 

Flight 26 12/10/92 The gains for large maneuvering 
turns were reduced on this flight and produced 
satisfactory results. 

Flight 27 12/10/92 The gains for small navigation 
turns were increased and produced a nearly perfect 
autonomous flight. The landing flare maneuver resulted 
in a vertical velocity at touchdown less than 1 ft/s at a 
point 662 ft from the target. 

Flight 28 12/10/92 After performing five successful 
autonomous landing flares, it was decided to deploy 
Flight 28 at an altitude of 8500 ft AGL. To return the 
vehicle to the landing site, ground control had to be used 
at high altitude, because it was discovered that the GPS 
short-term guidance did not function properly when the 
vehicle drifts backward in high winds. As a result, the 
software was modified to use the magnetic compass 
heading for short-term corrections. An auto mode landing 
profile from sonar altimeter initiation to touchdown is 
included in figure 3. 

Conclusions 

Under JSC sponsorship, NASA Dryden Flight 
Research Facility has developed and demonstrated a fully 
autonomous approach and landing system for application 
to future spacecraft recovery. Using existing 
technologies, the autonomous system was demonstrated 
during the last 2 months of contract year 1992 in a series 
of eight successful flights. The program was successful in 
proving the concept of autonomous landing using simple 
open-loop methods, and additional work during the next 
year will improve the knowledge base. A final report is in 
progress. Additional work during the next year is 
discussed below. 

Future Plans 

This flight test activity is being continued in fiscal 
year 1993 in three areas: upgraded software to include 
wind sensing, evaluation of alternative landing flare 
techniques, and evaluation of various lift-to-drag gliding 
parachutes. Aerodynamic instrumentation will be 
included in the spacecraft to allow for postflight analysis 
of vehicle performance. 

The first task will include the evaluation of a variety 
of parachutes including smaller, more maneuverable 
parachutes and high-glide paragliders. Measurements of 
turn rate, rate of descent, glide ratio, and flare 
performance will be recorded and compared. The 
addition of aerodynamic instrumentation including a 
“tattletale” type accelerometer and rate gyro package will 
also be included as part of this task to improve the quality 
of flight data received. 

The second task will consist of an evaluation of 
alternative landing flare techniques using the second 


vehicle modified with the addition of radio control. The 
trailing edge retraction flare using an actuator, while 
perfectly suitable for small models, will be difficult to 
incorporate into full-scale spacecraft because of weight 
and power requirements. A variety of methods for 
performing the landing flare maneuver will be 
investigated and their performance compared under a 
variety of wing loadings. Sensitivity to flare initiation 
altitude and vehicle dynamics at touchdown will be 
evaluated in the flights. 

The third task consists of upgrading flight algorithms 
to include some method for compensating for wind during 
the descent. Data from the existing magnetic compass 
and the GPS receiver could be used to compute wind 
magnitude and direction in real time. Ground-based 
systems for measuring wind profiles will also be 
investigated to uplink to the vehicle. 
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Figure 1. Flight Test Vehicle. 
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Abstract 

Current trends in avionics design and implementation 
are heading toward more extensive use of accepted 
standards in all areas of hardware and software design and 
implementation. Following development work over the 
last 5 years in the more general area of computer and 
information sciences standards work, a reference model 
for avionics has been developed compatible with the 
Institute of Electrical and Electronic Engineers (IEEE) 
P1003.0 reference model for application software 
portability and the International Organization for 
Standardization • Open Systems Interconnection (ISO 
OSI) reference model. This paper describes some of the 
aspects of the avionics reference model. This work was 
done over the last 2 years in a collaborative way between 
the Flight Data Systems Division and Lockheed 
Engineering and Sciences Company (LESC). 

Introduction 

The ISO established the first reference model for use 
with standards. Its purpose was to allow standards users 
and developers to work within a common framework. 

The developers would use the framework, or reference 
model, to define functionality and completeness of 
standard specifications. The users would use the 
reference model to develop profiles of selected and 
tailored standards that work together to meet specific 
program requirements. 

Over the last 5 years, the IEEE, through the Portable 
Operating System Interface (POSIX) P1003 committee, 
has been working on a broader reference model targeted 
for the development of profiles that allow application 
software portability and interoperability across 
heterogeneous platforms. The P1003.0 reference model is 
sufficiently generic to apply to a wide variety of platform 
types represented within the P1003 standards activities. 

The avionics reference model elaborates on the 
P1003.0 reference model to one more level of detail to 
identify significant interfaces and functions within the 
application platform that are not addressed by the P1003.0 
reference model. 

Problem Statement 

Obvious trends are being followed within the 
avionics development and user communities that point to 
continued and increased use of standards in the 
development of flight systems. The trend will not be 


aided by the ever increasing numbers of standards; it will 
only make it more difficult to select a compatible set. It 
was this same issue that forced the OSI community to 
adopt a reference model to provide a way of producing a 
compatible set of standards tailored for a specific 
application. Not only are network communications 
standards continuing to be developed, but the latest trends 
are in the definition of software interface standards or 
Application Program Interface Definitions. A reference 
model for avionics is needed that would provide a 
structure for developing profiles of standards that meet 
specific mission needs beyond network communications. 

Approach 

The work described here began with existing 
reference models within the standards communities, 
specifically, the OSI reference model [IS07498] and the 
IEEE POSIX P1003.0 reference model [IEEEP1003.0]. 
The limitation of the OSI model to communications 
prevented its expansion to the needs of the avionics 
reference model. The scope of the P1003.0 model is very 
broad, encompassing information systems from real time 
to batch, but because it included real-time capabilities, it 
was inferred that further specifications within that model 
would lead to a workable avionics model. Additionally, 
by starting with the P1003.0 model, the avionics model 
was assured of incorporating the OSI model since they are 
compatible. 

The relationships of the P1003.0 reference model to 
avionics has a long history. When the P1003.0 committee 
was formed, the first text presented to it consisted of 
extracts from a NASA Space Station Program 
Architecture Requirements document for the Space 
Station Information System. That document attempted to 
describe the overall Space Station command and 
telemetry information structure in terms of interfaces 
between the various elements from flight systems to 
ground systems and the standards that were to be utilized 
to effect communication interoperability. But, other 
requirements on the information system required software 
interoperability and portability. To architect such a 
requirement, another set of interfaces was defined having 
to do with the logical connectivity of software functions 
in flight systems and ground systems. This separation of 
physical communications interface standards 
requirements and software logical (i.e., nonphysical) 
connectivity formed the basis of the text presented to the 
P1003.0 committee. That concept has been carried out in 
the final P1003.0 reference model. The physical 
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connectivity interface is defined as the external entity 
interface (EEl), and the software logical interface is 
defined as the application program interface. 

To determine the range of possible mission specific 
requirements on an avionics system, an attempt was made 
to quantify the avionics performance requirements, at a 
high level, for current and future spaceflight systems. 
These requirements were compiled but showed no 
significant needs that would impact the eventual reference 
model. It is in the selection of standards for a specific 
mission that these performance requirements would have 
impacted. 

Because the work was performed within and for the 
Flight Data Systems Division, the reference model as it 
exists now is heavily oriented toward data system 
capabilities. We were limited in manpower to be able to 
expand the detail to other systems that are part of avionics 
in general. 

Results 

There are three components to the avionics reference 
model. The generic system architecture, which identifies 
high-level functional blocks and interfaces for the 
avionics along with operational systems, is not necessarily 
part of a vehicle. The generic functional architecture 
identifies generic atomic functions for Space Data 
Systems (additional functional architectures for other 
components of the avionics suite can and should be 
developed, but this was beyond the scope of our activity). 
The architecture interface model defines an interface class 
structure that is directly related to the P1003.0 reference 
model. This paper will describe the second two parts. 

All three are defined in the two documents produced from 
this project [WRAY1992-1] [WRAY1992-2]. 

Generic Functional Architecture 

Past and future avionics systems for spaceflight 
vehicles were reviewed, and the essential functional 
components of the space data system were identified and 
categorized. Five major functional categories were 
identified along with detailed functionality to two levels 
within each category. Table 1 provides the details of the 
functional components. This information is useful in 
identifying which subfunctions are required, based on a 
given mission requirements statement, and was used 
successfully in the development of a data system design 
for the Artemis common lunar lander. No locality is 
implied for these functions; in fact, these functions can be 
performed on the ground as well as within the spacecraft, 
depending on mission requirements. 

Architecture Interface Model 

The architecture interface model is structured around 
the concept of classes of interfaces. The interface model 
identifies six classes of interfaces that describe 


completely the connectivity within and external to an 
avionics system. The classes of interfaces are grouped by 
hardware-oriented interfaces, software-oriented interfaces, 
physical interfaces, and logical (or functional) interfaces. 

The classes of interfaces are also mapped into the two 
interfaces of the P1003.0 model EEI (hardware interfaces) 
and API (software interfaces). Figure 1 is a graphical 
representation of the avionics reference model, which 
includes the relationship to the POSIX P1003.0 reference 
model. 

Definitions 

A hardware interface is an interface between two 
hardware components or between a hardware component 
and a software component. 

A software interface is an interface between two 
software components. 

A physical interface is defined as the routing 
requirements associated with passing data from the source 
of the data to the end user of the data. Data are used by 
an entity in a physical manner if it passes the data on 
without using or changing the data; for example, network 
operating systems are physical interfaces to applications 
because they package or unpack data and send it to 
another network node. Both hardware and software 
physical interfaces apply. 

A lo gical interface is defined as the characteristic 
requirements associated with an interaction between a 
source of data and the end user of the data. For instance, 
a communications application that receives data from a 
global positioning system satellite formats the data into a 
package of information, and passes it to the guidance, 
navigation, and control (GN&C) application must define a 
"logical” interface with the GN&C application that 
defines the content and meaning of the data transferred. 
These data will pass through an arbitrary and mission- 
dependent number of “physical” interfaces. Logical 
interfaces normally exist only between software 
components; however, this is only because the 
functionality associated with logical interfaces is 
sufficiently complex to prohibit hardware implementation 
as yet. 

Interface Class Descriptions 

Class 1 hardware physical interfaces are the direct 
connections between different types of hardware such as 
those needed to enable buses and communications links 
between processors. 

Class 2 hardware-to-system software physical 
interfaces are the direct connections between hardware 
registers and software drivers, such as those needed to 
enable address registers to move bit patterns from 
hardware to software, and service drivers that can respond 
to the bit patterns. 

Class 3 system -soft ware-to-sy stem software physical 
interfaces are the direct connections between operating 
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system service code and local system services software 
code. 

Class 4 system software-to-other-system software 
logical interfaces are the indirect connections that enable 
local system service software within two physically 
separated application platforms to interoperate. 

Class 5 system-software-to-applications-software 
physical interfaces are the direct connections that enable 
software service code to access and process data from 
local application software code. 

Class 6 applications-software-to-applications- 
software logical interfaces are the indirect connections 
that enable an application originating data to pass the data 
to an application that needs to use the data, or enable an 
application needing data to determine the source from 
which the data must be obtained. This interface provides 
the indirect connections that allow applications in 
different systems or in the same system to communicate, 
thus enabling applications software to interact across 
system boundaries or within system boundaries to 
accomplish a mutual purpose. These interfaces may be 
applicable to applications executing in the same 
processor, in different processors in the same node, or in 
different systems. 

Use of Reference Model 

To use this interface model, a system user or 
developer will define the functions of the system at the 
interfaces and then select relevant standards as necessary. 
This process is called “profiling” within the standards 
community. This process will also identify areas where 
standards are not defined that require definition work for 
the system. 

Conclusions 

The next step for the reference model is to have it 
reviewed and modified by an interested standards setting 


body. That is currently in progress. The reference model 
was presented to the Society of Automotive Engineers in 
October 1992. They are currently reviewing the reference 
model and determining what action to take on it. We are 
continuing to pursue the expansion of the model in more 
detail within the flight data systems area and are 
beginning to develop a mode, state, and functional 
simulation model of a generic flight data system based on 
this work. 
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Table 1. Space Data System Services 


Standard Data 
Services Manager 

Data System 
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Operating System 

Data Base Manager 

Network Services 
Manager 

• Standard Services 

• Configuration 

• OS Kernel 

• File Service 

• Network Services 

Data Acquisition 

Manager 

- Process Management 

Controller 

Controller 

Controller 

- Upload Software Tables 

and Control 

- Sequential File 

- Network Command 

- Data Bus Services 

Change Management 

- Initialization and 

Services 

Verification 

- Sensor and Effector 

- Reconfiguration 

Configuration 

- Structured File 

- Network Stack 

Input/Output 

HW/SW 

Management 

Services 

Controller 

• Sensor Pre-Processing 

- Maintain System 

I/O Management 

- Distributed File 

- Network Queue 

Services 

configuration 

- Memory Management 

services 

Management 

- Distributed Data 

• Timing Service 

- CPU Management 

- Resource Management 

- Stack 

Read/Write 

Controller 

- Utility Services 

(in mass store) 


- Journal Manager 

- Monitor Timing Service 

- Privacy and Security 


• Network Manager 


- Automatic Timing 

Management 

• Distributed File 

- Network Coordinator 

• Standard Services 

Reconfiguration 


Transfer Service 

- Network Status 

Data distribution 

- Manual Timing 

• ADA RTE 

Controller 

Directory 

- Caution and Warning 

Reconfiguration 

- Ada Compiler Support 

- Internal System Node 

- Network Fault 

Processing 

- Update Timing 

- Ada/Non-Ada Mixed 

Transfers 

Detection 

- Telemetry Processing 

- History Processing 

- Resynchronize Timing 

• Data System 

Environment 

. OS/RTE 

- Recording Control 

- Ground Archives 

- Stack Layer 
Management 

- Network Security 

• Reports Generator 

Initialization, 

Extensions 

• File Transfer 

Management 

- tables 

Startup and 

- Real-Time Applications 

Access and 

- Network Performance 

- Forms 

Reconfiguration 

Task Control and 

Management 

Status 

- Outputs 

- Identify SW to be 

Communications 

Controller 


loaded 

- Load and Initialize SW 

- Ada Multi-Program 
Management 

- External Node 
Transfers 

• Remote Operator 


- Terminate Software 

- Inter-Process 

- Virtual/real file mapping 

• Network Directory 


• Process Initialization 
and Reload Requests 

• DSM Health, 

Status and FDIR 
Controller 

- Collect Health Status 
and Failure Data 

- Process Health Status 
and Failure data 

- Automatic 
Reconfiguration 

- Manual Reconfiguration 

- Update History Data 
Base 

Communications 

- Internal Bus 
Management 

- OS/RTE Initialization 
and Self Test 

- Precision Time 
Distribution 

• Non-Standard 
Processor Services 

(in mass store) 

Service Controller 

- Directory User Agent 

- Directory System 
Agent 

- Directory Information 
Base 

- Directory Information 
Tree 

• Network 

Association 

Controller 


Space Systems Technology 


74 







Figure 1. Representation of Avionics Reference Model and Its Relationship to the P1003.0 Reference Model. 
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